PDCCH candidates per slot of sSCell.Please refer to RP-193260 for detailed scope of the WI
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2)
R1-2006415 Work plan for Further MR-DC Enhancements Huawei
R1-2006670 Work plan for Rel17 WI on NR Dynamic spectrum sharing (DSS) Ericsson
[102-e-NR-DSS-DC_enh2-01] – Ravi (Ericsson) & Frank (Huawei)
Email discussion/approval using the summary as a starting point, focusing on high-level aspects
R1-2007442 Summary of NR Dynamic spectrum sharing (DSS) in Email discussion [102-e-NR-DSS-DC_enh2-01] Moderator (Ericsson)
Agreements:
· Following scheduling combinations are allowed/not allowed when cross-carrier scheduling from an SCell to PCell/PSCell is configured
o self-scheduling on PCell/PSCell is allowed
o cross-carrier scheduling from PCell/PSCell to another SCell is not allowed
o self-scheduling on the ‘SCell used for scheduling PCell/PSCell’ is allowed
o cross-carrier scheduling from the ‘SCell used for scheduling PCell/PSCell’ to another serving cell is allowed
o cross-carrier scheduling from another serving cell to the ‘SCell used for scheduling PCell/PSCell’ is not allowed
· FFS: Search space and DCI format handling for the allowed cases above
Agreement:
· Configuring 2 or more Scells to schedule the PCell/PSCell is not allowed.
Update on 8/27 for the study on PDCCH of P(S)Cell/SCell scheduling PDSCH on multiple cells using a single DCI:
Agreements:
· For the study on single DCI scheduling PDSCH on two cells
o Consider the following scenarios as baseline for evaluation
§ UE configured with Inter-band CA with PCell and an SCell
· PCell for the UE is operated on a DSS carrier (i.e., same carrier is also used for serving LTE users)
· Case 1: Different SCS for PCell and SCell
· Case 2: Same SCS for PCell and Scell
o Additional scenarios can also be evaluated, e.g. as below
§ Intra-band CA case with multiple serving cells having same SCS (all cells operated on non DSS carriers)
§ Inter-band CA case with PCell and more than one SCell (at least the SCells are operated on non DSS carriers)
§ Note: other combinations not precluded
· Note: Further details of evaluation framework (including carrier BW, slot format etc.) to be discussed in next stage
Focusing on high-level concepts
R1-2005409 Discussion on Scell scheduling Pcell vivo
R1-2005440 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2005696 Disucssion on cross-carrier scheduling from Scell to Pcell CATT
R1-2005900 On SCell scheduling PCell transmissions Intel Corporation
R1-2006063 Cross-carrier scheduling OPPO
R1-2006176 Cross-carrier scheduling from SCell to Pcell Samsung
R1-2006281 Discussion on cross-carrier scheduling from Scell to Pcell Spreadtrum Communications
R1-2006318 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2006362 Discussion on cross-carrier scheduling for NR DSS ETRI
R1-2006366 Discussion on Cross-carrier scheduling from SCell to PCell Beijing Xiaomi Mobile Software
R1-2006405 Discussion on the PDCCH of SCell scheduling PDSCH or PUSCH on P(S)Cell Huawei, HiSilicon
R1-2006469 Cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell
R1-2006473 SCell scheduling PCell InterDigital, Inc.
R1-2006509 Views on Rel-17 DSS SCell scheduling PCell Apple
R1-2006671 Enhanced cross-carrier scheduling for DSS Ericsson
R1-2006749 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2006756 Discussion on PDCCH of SCell scheduling PDSCH or PUSCH on PCell ASUSTeK
R1-2006833 Views on cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
Focusing on study whether or not to support the feature first
R1-2006987 Discussion on joint scheduling vivo (Revision on R1-2005410)
R1-2005441 Discussion on Multi-cell PDSCH Scheduling via a Single DCI ZTE
R1-2005628 On Multi-cell PDSCH scheduling via a single DCI MediaTek Inc.
R1-2005697 Discussion on multi-cell PDSCH scheduling via a single DCI CATT
R1-2005901 On 2-cell scheduling via single DCI Intel Corporation
R1-2005909 On support of Single DCI scheduling two cells Nokia, Nokia Shanghai Bell
R1-2006064 Multi-cell PDSCH scheduling via a single DCI OPPO
R1-2006177 On the use of one DCI format for scheduling on two cells Samsung
R1-2006282 Discussion on multi-cell PDSCH scheduling via a single DCI Spreadtrum Communications
R1-2006319 Discussion on multi-cell PDSCH scheduling via a single DCI LG Electronics
R1-2006413 Discussion on the PDCCH of P(S)Cell/SCell scheduling PDSCH on mulitple cells using a single DCI Huawei, HiSilicon
R1-2006474 A single DCI scheduling multi-cell InterDigital, Inc.
R1-2006510 Views on Rel-17 DSS Multi-cell PDSCH scheduling via a single DCI Apple
R1-2006583 Discussion on multi-cell PDSCH scheduling via a single DCI ASUSTeK
R1-2006672 Discussion on single DCI scheduling PDSCH on multiple cells Ericsson
R1-2006750 Discussion on multi-cell PDSCH scheduling via a single DCI for NR DSS NTT DOCOMO, INC.
R1-2006834 Views on multi-cell PDSCH scheduling via a single DCI Qualcomm Incorporated
Focusing on high-level concepts
R1-2005411 Discussion on efficient activation/de-activation mechanism for Scells vivo
R1-2005442 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2005629 On supporting efficient activation mechanism for SCells in NR CA MediaTek Inc.
R1-2005698 Disucssion on efficient activation/de-activation mechanism for Scell in NR CA CATT
R1-2005908 On low latency Scell activation Nokia, Nokia Shanghai Bell
R1-2006065 Efficient activation/de-activation for Scell OPPO
R1-2006178 On efficient activation/de-activation mechanism for Scells Samsung
R1-2006283 Discussion on efficient activation/de-activation mechanism for SCells in NR CA Spreadtrum Communications
R1-2006511 Views on Rel-17 DSS SCells efficient activation/de-activation Apple
R1-2006673 Reduced Latency SCell Activation Ericsson
R1-2006751 Discussion on efficient activation/deactivation mechanism for SCells NTT DOCOMO, INC.
R1-2006754 Efficient activation/deactivation of SCell ASUSTEK COMPUTER (SHANGHAI)
R1-2006835 Views on efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2006927 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2007422 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2007423 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
Working Assumption:
At least for the case of known cell, temporary RS is supported to expedite the activation process during the SCell activation procedure for efficient SCell activation for both FR1 and FR2:
· The temporary RS should provide at least the functionalities of AGC settling and time/frequency tracking during SCell activation procedure.
· FFS potential functionalities of CSI measurement/acquisition and cell search
Agreements:
TRS is selected as temporary RS for Scell activation
· If more functionalities are confirmed to be supported by temporary RS, other RS candidates, e.g. aperiodic CSI-RS, P/SP-CSI RS, SRS and RS based on SSS/PSS, are not precluded.
· The TRS should be triggered by DCI or MAC-CE. FFS which exact triggering command.
Agreements:
UEs measure the triggered temporary RS during Scell activation procedure no earlier than a slot m:
· FFS timeline values m which may need coordination with RAN4.
· FFS if the triggered temporary RS can be associated with a BWP, then the measurement above is independent of the activation state of the BWP.
Agreements:
Companies are encouraged to provide design details of temporary RS next meeting, at least including:
· TRS structure, e.g. whether to fully reuse existing Rel-15/16 TRS structure and configuration restriction (refer to S5.1.6.1.1 of TS 38.214), or any modification
· QCL information, if any
· Triggering command: DCI format/fields or MAC-CE fields
· Triggering timeline/scheduling offset
Please refer to RP-193260 for detailed scope of the WI
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2)
R1-2009205 Work plan for Rel17 WI on NR Dynamic spectrum sharing (DSS) Ericsson
R1-2009046 Cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell
On Search Space monitoring:
Proposal 1: When the PCell is configured to be cross-carrier scheduled by an SCell, the UE monitors the cross-carrier scheduling PDCCH at least in the USS of the scheduling SCell.
· FFS monitoring USS also on Pcell
Proposal 2: When the PCell is configured to be cross-carrier scheduled by an SCell, the UE can be configured to monitor the CSS type 3 for power control either in the PCell or in the SCell.
Proposal 3: Configuration of TYPE0/0A/1/2 CSS on the SCell is not allowed.
Proposal 4: BD/CCE limits are counted over both scheduling cells (PCell and SCell) and determined for scheduled PCell according to current specifications.
· if scheduling PCell and SCell are of different SCS, the higher SCS is used for determination of scheduled cell BD/CCE limits, and
· overbooking is allowed
Proposal 5: To support SCell to PCell fallback also for non-fall-back DCI formats, support USS on both self-scheduling the PCell and on the X-scheduling SCell of a scheduled Pcell. R16 SS group switching feature may be used to dynamically share PDCCH monitoring candidates between Pcell and Scell.
On DCI formats:
Observation 1: As the DCI formats 0_0/1_0 do not carry the CIF field, there is no need to monitor them in the scheduling SCell for cross-carrier scheduling.
Poposal 6: No changes are introduced to the DCI format 0_0/1_0 monitoring, i.e. they are monitorired for self-scheduling in PCell in CSS and USS, and for self-scheduling in the SCell in the USS.
Proposal 7: The rules for DCI format relation to search spaces are not modified.
On the location of the uplink channels:
Proposal 8: The requirement to have the PCell configured with the PUSCH/PUCCH/SRS for non-CA case are not modified
Proposal 9: The requirement to have the PCell configured with the PUCCH for CA case with single PUCCH group is not modified
Decision: The document is noted.
R1-2007579 Discussion on SCell PDCCH scheduling P(S)Cell PDSCH or PUSCH Huawei, HiSilicon
R1-2007695 Discussion on Scell scheduling Pcell vivo
R1-2007839 Disucssion on cross-carrier scheduling from Scell to Pcell CATT
R1-2008062 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2008110 Discussion on cross-carrier scheduling from SCell to Pcell Spreadtrum Communications
R1-2008195 Cross carrier scheduling from SCell to Pcell Samsung
R1-2008284 Discussion on cross-carrier scheduling from Scell to Pcell OPPO
R1-2008451 Views on Rel-17 DSS SCell scheduling PCell Apple
R1-2008695 Discussion on cross-carrier scheduling from SCell to PCell ASUSTeK
R1-2008830 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2009003 On SCell scheduling PCell transmissions Intel Corporation
R1-2009023 Cross-carrier scheduling from SCell to Pcell ETRI
R1-2009040 Discussion on Cross-carrier scheduling from SCell to Pcell Xiaomi
R1-2009085 Search space monitoring to support SCell scheduling PCell InterDigital, Inc.
R1-2009110 Cross-carrier scheduling (from Scell to Pcell) Lenovo, Motorola Mobility
R1-2009195 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2009206 Enhanced cross-carrier scheduling for DSS Ericsson
R1-2009277 Views on cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
[103-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion/approval for CCS
R1-2009486 Summary of Email discussion [103-e-NR-DSS-01] Moderator (Ericsson)
Decision from GTW sessions,
Agreements:
· When CCS from an SCell (sSCell) to PCell/PSCell is configured, UE monitors Type 0/0A/1/2 CSS sets (for the DCI formats associated with those SS sets) only on the PCell/PSCell and not on the sSCell
o Note: UE monitors Type 0/0A/2 CSS only on PCell while Type 1 CSS can be monitored on PCell/PSCell
Decision: As per email decision posted on Nov.12th,
Conclusion
· When CCS from sSCell to PCell/PSCell is configured, the configuration of Type 3 CSS set for DCI formats 2_0, 2_1, 2_2, 2_3, 2_4 and applicability of the information in the DCI formats are the same as in Rel-15/Rel-16
o FFS: DCI format 2_5 and DCI Format 2_6 handling
· Note: The SCell configured with CCS to Pcell/PSCell is referred to as ‘sSCell’
· When the PCell/PSCell and sSCell use different numerologies, the PDSCH reception preparation time between the PDCCH on the sSCell and the PDSCH on the PCell/PSCell is applied (i.e., as specified in TS38.214 Section 5.5).
Decision: As per email decision posted on Nov.13th,
Agreements:
· Discuss in RAN1#104-e how to handle ‘DCI formats 0_1,1_1,0_2,1_2 scheduling PDSCH/PUSCH on PCell/PSCell’ from USS set(s), when CCS from sSCell to PCell/PSCell is configured.. Below alternatives can be considered in the discussion (other alternatives are not precluded)
·
Below
alternatives can be considered in the discussion (other alternatives are not
precluded)
o
Alt 1: When CCS from sSCell to PCell/PSCell is configured, UE cannot be configured to monitor DCI formats
0_1,1_1,0_2,1_2 on PCell/PSCell USS set(s), and can be configured to monitor
them only on the sSCell USS set(s)
o
Alt 2: When CCS from sSCell to PCell/PSCell is configured, UE can be configured to monitor DCI formats
0_1/1_1/0_2/1_2 on PCell/PSCell USS set(s), and/or on
sSCell USS set(s). The PDCCH monitoring is based on following alternatives
(other alternatives are not precluded)
§ Alt 2-1:
· UE can monitor DCI formats 0_1,1_1,0_2,1_2 on both PCell USS set(s) and sSCell USS sets simultaneously
o FFS
activation/deactivation of scheduling from sSCell to PCell/PSCell
§ Alt 2-2:
· Dynamic switching of PDCCH monitoring of DCI formats 0_1,1_1,0_2,1_2 between monitoring on PCell/PSCell USS sets and monitoring on sSCell USS sets is supported
o
FFS: Details of switching
mechanism (e.g. based on SS group switching,
based on BWP switching,…)
· UE does not monitor DCI formats 0_1,1_1,0_2,1_2 on both PCell USS set(s) and sSCell USS sets simultaneously
§ Alt 2-3:
· UE does not monitor the same DCI format on both PCell USS set(s) and sSCell USS sets simultaneously. UE can monitor some DCI formats on sSCell USS sets and other DCI formats on PCell/PSCell USS sets simultaneously
§ Alt 2-4:
· The USS set(s) on PSCell/PCell and the USS set(s) on sSCell are configured such that UE does not monitor DCI formats 0_1,1_1,0_2,1_2 on both PCell USS set(s) and sSCell USS set(s) simultaneously
· FFS following aspects
o Impact of sSCell activation/deactivation and sSCell dormancy
o
Impact on BD/CCE limit
handling including considering PDCCH monitoring
on CSS sets and PDCCH monitoring of ‘DCI formats 0_0, 1_0 scheduling
PUSCH/PDSCH on PCell/PSCell’
o Whether PDCCH overbooking on sSCell is supported or not supported and impact (if any) on overbooking handling on PCell/PSCell
o Impact from different numerologies between PDCCH on the PCell/PSCell and that on the sSCell
o Whether or not to have mechanism for activation/deactivation of scheduling from sSCell to PCell/PSCell
o USS configuration details (e.g. handling of
USS type (self-scheduling, cross carrier scheduling) for a configured USS set configured
for scheduling of in PCell/PSCell)
Final summary in:
R1-2009806 Summary#2 of Email discussion [103-e-NR-DSS-01] Moderator (Ericsson)
Focusing on study whether or not to support the feature first
R1-2008929 Discussion on multi-cell PDSCH scheduling via a single DCI Lenovo, Motorola Mobility
§ Proposal 1: Support using a single DCI to schedule two PDSCHs on two carriers.
§ Proposal 2: Further study payload size reduction, DCI size budget and HARQ-ACK codebook determination.
Decision: The document is noted.
R1-2007580 Discussion on multi-carrier scheduling using single PDCCH Huawei, HiSilicon
R1-2007696 Discussion on joint scheduling vivo
R1-2007840 Discussion on multi-cell PDSCH scheduling via a single DCI CATT
R1-2008063 Discussion on multi-cell PDSCH scheduling via a single DCI LG Electronics
R1-2008111 Discussion on multi-cell PDSCH scheduling via a single DCI Spreadtrum Communications
R1-2008196 On the use of one DCI format for scheduling on two cells Samsung
R1-2008285 Discussion on multi-cell PDSCH scheduling via a single DCI OPPO
R1-2008452 Views on Rel-17 DSS Multi-cell PDSCH scheduling via a single DCI Apple
R1-2008696 Discussion on multi-cell PDSCH scheduling via a single DCI ASUSTeK
R1-2008831 Discussion on Multi-cell PDSCH Scheduling via a Single DCI ZTE
R1-2008835 Multi-cell scheduling and dormancy Charter Communications
R1-2008963 Evaluation on On Multi-cell PDSCH Scheduling via Single DCI MediaTek Inc.
R1-2009004 On 2-cell scheduling via single DCI Intel Corporation
R1-2009024 Discussion on multi-cell PDSCH scheduling via a single DCI ETRI
R1-2009047 On support of Single DCI scheduling two cells Nokia, Nokia Shanghai Bell
R1-2009086 Discussion on the support of single DCI scheduling multi-cell InterDigital, Inc.
R1-2009196 Discussion on multi-cell PDSCH scheduling via a single DCI for NR DSS NTT DOCOMO, INC.
R1-2009207 Study on single DCI scheduling PDSCH on multiple cells Ericsson
R1-2009278 Views on multi-cell PDSCH scheduling via a single DCI Qualcomm Incorporated
[103-e-NR-DSS-02] – Haipeng (Lenovo)
Email discussion/approval for multi-cell PDSCH scheduling via a single DCI
R1-2009559 Feature lead summary#1 on multi-cell scheduling via a single DCI Moderator (Lenovo)
Decision from GTW session,
Agreements:
Further study multi-cell PDSCH scheduling via a single DCI with below simulation assumptions:
Table 1: Link level simulation assumptions
|
Parameters |
Values |
|
Carrier frequency |
Option 1: Inter-band CA (700MHz + 4GHz) Intra-band CA (2GHz)
Option 2: Only 4GHz is considered |
|
SCS |
15 kHz for 700MHz/2GHz 30 kHz for 4GHz |
|
Bandwidth |
Option 1: Baseline: PCell 10MHz + SCell 10/40MHz Optional: PCell 20MHz + SCell 20/40/100MHz
Option 2: Baseline: Scheduling cell 100 MHz Optional: Scheduling cell 20 MHz |
|
Channel model |
TDL-C |
|
Delay spread |
300 ns |
|
Number of symbols for CORESET |
[1], 2 or 3 |
|
CORESET BW (contiguous PRB allocation) |
24/48/96 RBs depending on the bandwidth |
|
CCE-to-REG mapping |
Interleaved, [non-interleaved] |
|
REG bundle size |
6 |
|
Interleaver size |
2 |
|
DCI payload size (excluding CRC) |
Single PDSCH scheduling: 60 bits as baseline payload size Multi-cell PDSCH scheduling: 72/84/96/104 bits |
|
BLER target for multi-cell scheduling DCI |
Option 1: 1% Option 2: 0.5% |
|
Number of BS antennas |
2 Tx for 700MHz/2GHz carrier frequency 4 Tx for 4GHz |
|
Number of UE antennas |
2 Rx for 700MHz/2GHz carrier frequency 4 Rx for 4GHz carrier frequency |
|
Modulation |
QPSK |
|
Channel coding |
Polar code |
|
UE speed |
3km/h |
|
Aggregation level |
1/2/4/8/16 |
|
Tx Diversity |
One port precoder cycling |
Note 1: For two-cell scheduling via a single DCI, PDCCH transmitted on SCell schedules one PDSCH on the SCell and another PDSCH on PCell.
Note 2: For comparison, for single-cell scheduling, one PDCCH transmitted on SCell schedules one PDSCH on the SCell via self-scheduling and another PDCCH transmitted on the SCell schedules another PDSCH on PCell via cross-carrier scheduling.
Further discussion which rows are applicable to the scheduling cell/the scheduled cell for PDCCH
Decision: As per email decision posted on Nov.13th,
Agreements: Further study with below simulation assumptions:
Simulation scenarios:
· For two-cell scheduling via a single DCI, PDCCH transmitted on a first cell schedules one PDSCH on the first cell and another PDSCH on a second cell.
· For single-cell scheduling (baseline), one PDCCH transmitted on a first cell schedules one PDSCH on the first cell via self-scheduling and another PDCCH transmitted on the first cell schedules another PDSCH on a second cell via cross-carrier scheduling.
Simulation assumptions on carrier frequency, SCS, antenna configuration, carrier bandwidth as well as CORESET configuration
· Combination 1: 2 GHz, 15 kHz SCS, 2 Tx, 2 Rx, 20 MHz carrier BW, 2-symbol CORESET with 96RBs
· Combination 2: 4 GHz, 30 kHz SCS, 4 Tx, 4 Rx, 100 MHz carrier BW, 1-symbol CORESET with 270RBs
· [Combination 3: 700MHz, 15 kHz SCS, 2 Tx, 2 Rx, 10 MHz carrier BW, 3-symbol CORESET with 48RBs]
· [Combination 4: 4GHz, 30 kHz SCS, 4 Tx, 4 Rx, 40 MHz carrier BW, 2-symbol CORESET with 96RBs]
Payload size of two-cell scheduling DCI (excluding CRC):
· 60 for single-cell scheduling DCI (baseline).
· 72/84/96/108 for two-cell scheduling DCI.
o Companies are encouraged to report how the values are obtained, e.g., via separate or shared fields in DCI format.
Target BLER for two-cell scheduling DCI: 1% (baseline), 0.5%(optional)
Regarding the CCE-to-REG mapping, based on the agreed interleaved CCE-to-REG mapping, whether to adopt non-interleaved CCE-to-REG mapping is up to the proponent.
Agreements:
· Further study with below simulation assumptions:
Table 2: System level simulation assumptions
|
Parameters |
Values |
|
Carrier frequency |
For scheduling cell, follow agreed link level simulation assumptions For scheduled cell, consider 700MHz/2GHz with 10/20MHz BW (LTE overhead on DSS carrier can be optionally provided, up to proponent) |
|
SCS |
|
|
Simulation bandwidth |
|
|
BS antenna height |
25 m |
|
UE height |
1.5m |
|
TRP transmit power |
46 dBm for 10MHz |
|
Scenario |
Urban Macro |
|
ISD |
500m |
|
TRP antenna configuration |
(M,N,P,Mg,Ng;Mp,Np)= (1,2,2,1,1;1,1) for 700MHz (M,N,P,Mg,Ng;Mp,Np)= (2,8,2,1,1;1,1) for 2GHz (M,N,P,Mg,Ng;Mp,Np)= (8,4,2,1,1;1,1) for 4GHz |
|
UE antenna configuration |
(M,N,P,Mg,Ng;Mp,Np)= (1,1,2,1,1;1,1) for 700MHz/2GHz (M,N,P,Mg,Ng;Mp,Np)= (1,2,2,1,1;1,1) for 4GHz |
|
Device deployment |
80% indoor, 20% outdoor |
|
UE speeds of interest |
Indoor users: 3km/h |
|
Outdoor users (in-car): 30 km/h |
|
|
BS noise figure |
5 dB |
|
BS antenna element gain |
8 dBi |
|
UE noise figure |
9 dB |
|
Thermal noise level |
-174 dBm/Hz |
|
Traffic |
Full Buffer(baseline), FTP model 1 or 3 up to company |
|
Macro sites |
19 |
|
Number of UEs per cell |
10/15/20 UEs |
|
Downtilt |
102° |
|
Minimum BS to UE distance |
35m |
Final summary in:
R1-2009815 Final Feature lead summary on multi-cell scheduling via a single DCI Moderator (Lenovo)
R1-2008832 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
Reference signal design
· Proposal 1:
o Reuse the existing Rel-15/Rel-16 TRS structure for temporary RS.
o Send LS to RAN4 to check whether the current two TRS patterns (i.e., 1-slot with two TRSs resources and 2-slot with four TRSs resources) are sufficient for AGC settling and time/frequency tracking during SCell activation.
§ If Yes, then A-TRS is adopted as the temporary RS.
§ If Not, then P-TRS/SP-TRS is adopted as the temporary RS.
· Proposal 2: RAN1 further discusses whether to adopt TRS or CSI-RS for channel measurement/acquisition during SCell activation.
Triggering command for temporary RS
· Proposal 3: RAN1 further discusses and compares the following options for SCell activation
o Option1: One MAC-CE to activate SCell(s) and another MAC-CE to trigger/activate the temporary RS(s);
o Option2: A combined MAC-CE to activate SCell(s) and trigger/activate the temporary RS(s);
o Option3: One MAC-CE to activate SCell(s) and one DCI to trigger/activate the temporary RS(s);
o Option4: One combined DCI to activate SCell(s) and trigger/activate the temporary RS(s).
· Proposal 4: A combined command is used to activate the SCell and activate/trigger the corresponding TRS. Further study whether this combined command is also used to trigger the CSI-RS for channel measurement.
· Proposal 5: In order to determine whether to adopt the DCI based solution or MAC-CE based solution, RAN1 first finalizes both the DCI based solution and MAC-CE based solution and then compare these different solutions, considering the activation latency, power consumption and etc.
· Proposal 6: Regarding MAC-CE based solution for fast SCell activation
o HARQ-ACK feedback is needed for this MAC-CE
o Target SCell ID is included in the MAC-CE
o TRS triggering information (e.g., trigger state ID) is included in the MAC-CE
· Proposal 7: Regarding DCI based solution for fast SCell activation
o TRS trigger state ID is included in the DCI
o Further study how to indicate the target SCell ID, e.g., add new DCI field or reuse the SCell dormancy indicator
o Futher study whether DL DCI or UL DCI is adopted
o Further study how to trigger HARQ-ACK for UL DCI (if UL DCI is selected)
Timeline
· Proposal 8: Regarding temporary RS for SCell activation,
o The duration between SCell activation command and reference signal for AGC settling and time/frequency tracking should be sufficient for L1/L2 signaling processing, RF warm-up and BWP activation.
o The reference signal for channel measurement is transmitted later than the reference signal for AGC settling and time/frequency tracking.
Decision: The document is noted.
R1-2007548 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2007697 Discussion on efficient activation/de-activation mechanism for Scells vivo
R1-2007841 Disucssion on efficient activation/de-activation mechanism for Scell in NR CA CATT
R1-2008112 Discussion on efficient activationde-activation mechanism for SCells in NR CA Spreadtrum Communications
R1-2008197 On efficient activation/de-activation mechanism for Scells Samsung
R1-2008286 Discussion on efficient activation/de-activation for Scell OPPO
R1-2008322 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2008453 On efficient SCell Activation/Deactivation Apple
R1-2008713 Efficient activation/deactivation of SCell ASUSTeK
R1-2008849 Discussion on efficient activation mechanism for SCells NEC
R1-2008968 On supporting efficient activation mechanism for SCells in NR CA MediaTek Inc.
R1-2009005 On efficient activation/de-activation for SCells Intel Corporation
R1-2009048 On low latency Scell activation Nokia, Nokia Shanghai Bell
R1-2009197 Discussion on efficient activation/deactivation mechanism for SCells NTT DOCOMO, INC.
R1-2009208 Reduced Latency SCell Activation Ericsson
R1-2009279 Views on efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2009569 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
[103-e-NR-DSS-03] – Frank (Huawei)
Email discussion/approval for efficient activation/de-activation mechanism for SCells in NR CA
R1-2009666 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2009712 Summary#3 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
Decision from GTW sessions,
Agreements:
As working assumption, with respect to efficient SCell activation, reuse existing Rel-15/16 TRS structure for temporary RS
Decision: As per email decision posted on Nov.13th,
Agreements:
For efficient SCell activation, discuss and agree from the following alternatives at RAN1#104-e
· Alt2: Triggering of temporary RS separately from SCell activation command is not precluded and both ‘separate’ triggers (examples below) and ‘integrated’ triggers (examples in Alt 1) are considered for SCell activation
R1-2009786 [Draft] LS on temporary RS for efficient SCell activation in NR CA Huawei
Decision: As per email decision posted on Nov.13th, the draft LS is endorsed. Final LS is approved in R1-2009798.
Final summary in:
R1-2009800 Final Summary of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
Please refer to RP-193260 for detailed scope of the WI
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2)
R1-2102198 Sesson notes for 8.13 (NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (Samsung)
R1-2101560 Work plan for Rel17 WI on NR Dynamic spectrum sharing (DSS) Ericsson
R1-2100110 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2100186 Discussion on cross-carrier scheduling from Scell to Pcell OPPO
R1-2100193 Discussion on SCell PDCCH scheduling P(S)Cell PDSCH or PUSCH Huawei, HiSilicon
R1-2100358 Discussion on cross-carrier scheduling from Scell to Pcell CATT
R1-2100473 Discussion on Scell scheduling Pcell vivo
R1-2100677 On SCell scheduling PCell transmissions Intel Corporation
R1-2100694 Discussion on cross carrier scheduling for NR DSS NEC
R1-2100719 Om cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell
R1-2100794 Discussion on cross-carrier scheduling from SCell to PCell Spreadtrum Communications
R1-2100885 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2100992 Cross-carrier scheduling (from Scell to Pcell) Lenovo, Motorola Mobility
R1-2101066 Discussion on cross-carrier scheduling from SCell to Pcell CMCC
R1-2101088 Cross-carrier scheduling from SCell to Pcell ETRI
R1-2101100 Discussion on Cross-carrier scheduling from SCell to PCell Xiaomi
R1-2101237 Cross-carrier scheduling from SCell to PCell Samsung
R1-2101292 USS monitoring in sSCell and PCell InterDigital, Inc.
R1-2101362 Views on Rel-17 DSS SCell scheduling PCell Apple
R1-2101490 Cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
R1-2101561 Enhanced cross-carrier scheduling for DSS Ericsson
R1-2101632 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2101655 Discussion on cross-carrier scheduling from Scell to Pcell ASUSTeK
[104-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion/approval for CCS
- 1st check point: Jan 27
- 2nd check point: Feb 1
- 3rd check point: Feb 5
R1-2101863 Summary of Email discussion [104-e-NR-DSS-01] Moderator (Ericsson)
Agreement
When CCS from sSCell to PCell/PSCell is configured,
FFS: Whether this agreement requires RAN1 specification impact.
Agreement
When CCS from sSCell to PCell/PSCell is configured,
· Simultaneous reception of a) unicast PDSCH on PCell/PSCell scheduled from PCell/PSCell and b) unicast PDSCH on PCell/PSCell scheduled from sSCell is not allowed
· Simultaneous transmission of a) PUSCH on PCell/PSCell scheduled from PCell/PSCell and b) PUSCH on PCell/PSCell scheduled from sSCell is not allowed
· Note: Simultaneous implies full/partial time overlapping
FFS: Whether this agreement requires RAN1 specification impact.
Agreement
· When CCS from sSCell to PCell/PSCell is configured, CA activation/deactivation operation for the sSCell is supported
R1-2102018 Summary#2 of Email discussion [104-e-NR-DSS-01] Moderator (Ericsson)
R1-2102101 Summary#3 of Email discussion [104-e-NR-DSS-01] Moderator (Ericsson)
Working Assumption
Agreement
· When CCS from sSCell to PCell/PSCell is configured, UE monitors ‘DCI formats 0_0 and 1_0 in CSS that schedule PDSCH/PUSCH on PCell/PSCell’ only on the PCell/PSCell and not on the sSCell
Final summary in R1-2102236.
Focusing on study whether or not to support the feature first
R1-2101789 Discussion on Multi-cell PDSCH Scheduling via a Single DCI ZTE (rev of R1-2100111)
R1-2100187 Discussion on multi-cell PDSCH scheduling via a single DCI OPPO
R1-2100194 Discussion on multi-carrier scheduling using single PDCCH Huawei, HiSilicon
R1-2100359 Discussion on multi-cell PDSCH scheduling via a single DCI CATT
R1-2100474 Discussion on joint scheduling vivo
R1-2100611 On Multi-cell PDSCH Scheduling via Single DCI MediaTek Inc.
R1-2100678 On 2-cell scheduling via single DCI Intel Corporation
R1-2100720 On support of Single DCI scheduling two cells Nokia, Nokia Shanghai Bell
R1-2100771 Discussion on multi-cell PDSCH scheduling via a single DCI Lenovo, Motorola Mobility
R1-2100886 Discussion on multi-cell PDSCH scheduling via a single DCI LG Electronics
R1-2101089 Discussion on multi-cell PDSCH scheduling via a single DCI ETRI
R1-2101238 Considerations for scheduling on two cells using a single DCI format Samsung
R1-2101293 On the support of single DCI scheduling multi-cell InterDigital, Inc.
R1-2101363 Views on Rel-17 DSS Multi-cell PDSCH scheduling via a single DCI Apple
R1-2101491 Multi-cell PDSCH scheduling via a single DCI Qualcomm Incorporated
R1-2101562 Study on single DCI scheduling PDSCH on multiple cells Ericsson
R1-2101633 Discussion on multi-cell PDSCH scheduling via a single DCI for NR DSS NTT DOCOMO, INC.
R1-2101657 Discussion on multi-cell PDSCH scheduling via a single DCI ASUSTeK
[104-e-NR-DSS-02] – Haipeng (Lenovo)
Email discussion/approval for multi-cell PDSCH scheduling via a single DCI
- 1st check point: Jan 27
- 2nd check point: Feb 1
- 3rd check point: Feb 5
R1-2101864 Feature lead summary #1 on multi-cell scheduling via a single DCI Moderator (Haipeng)
R1-2101912 Feature lead summary #2 on multi-cell scheduling via a single DCI Moderator (Haipeng)
R1-2102138 Feature lead summary #4 on multi-cell scheduling via a single DCI Moderator (Haipeng)
Agreement
Agreement
The observations for multi-cell PDSCH scheduling via a single DCI to be summarized in the status report along with explantion on different combinations that were considered for submission to RAN.
R1-2100045 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2100112 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2100188 Discussion on efficient activation/de-activation for Scell OPPO
R1-2100192 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2100360 Discussion on efficient activation and de-activation mechanism for SCell in NR CA CATT
R1-2100475 Discussion on efficient activation/de-activation mechanism for Scells vivo
R1-2100679 On efficient activation/de-activation for SCells Intel Corporation
R1-2100695 Discussion on efficient activation mechanism for SCells NEC
R1-2100721 On low latency Scell activation Nokia, Nokia Shanghai Bell
R1-2100795 Discussion on efficient activation/de-activation mechanism for SCells in NR CA Spreadtrum Communications
R1-2101067 Discussion on efficient activation/de-activation mechanism for SCells CMCC
R1-2101239 On efficient activation/de-activation mechanism for Scells Samsung
R1-2101294 Fast SCell Activation InterDigital, Inc.
R1-2101364 On Efficiency Activation/De-activation for SCells in CA Apple
R1-2101492 Efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2101563 Reduced Latency SCell Activation Ericsson
R1-2101566 Efficient activation/deactivation of SCell ASUSTeK
R1-2101634 Discussion on efficient activation/deactivation mechanism for SCells NTT DOCOMO, INC.
[104-e-NR-DSS-03] – Frank (Huawei)
Email discussion/approval for efficient activation/de-activation mechanism for SCells in NR CA
- 1st check point: Jan 27
- 2nd check point: Feb 1
- 3rd check point: Feb 5
R1-2101932 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
Working Assumption
For efficient SCell activation with assistance of temporary RS, a SSB of the to-be-activated SCell can be indicated as a QCL source for the temporary RS in case of known SCell
· FFS: QCL type
· FFS: the case of unknown SCell
· FFS: other QCL source, e.g. the SSB/P-TRS of another active cell
R1-2101933 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
Agreement
For efficient activation of SCells, down select at least one option from below:
· Option 1a: MAC CE(s) contained in a single PDSCH to trigger both SCell activation and corresponding temporary RS(s)
o Details FFS including timeline design for receiving temporary RS
· Option 1b: A single DCI to trigger both SCell activation and corresponding temporary RS(s)
o Details FFS including potential impact on SCell activation related procedures and, e.g. timeline design for SCell activation and for receiving temporary RS
o FFS: The same DCI for SCell deactivation
· Option 2: A Rel-15/16 SCell activation MAC-CE to trigger SCell activation and a Rel-15/16 DCI to trigger corresponding temporary RS(s) with enhancement of timeline
o Details FFS including timeline design for receiving a DCI trigger of temporary RS, and for receiving temporary RS
· Note: Companies are encouraged to provide complete solutions for fast SCell activation.
· Note: the previous agreement on the definitions of Alt 1 and Alt 2 is still effective
Please refer to RP-193260 for detailed scope of the WI
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2)
R1-2103986 Sesson notes for 8.13 (NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (Samsung)
R1-2102309 Discussion on SCell PDCCH scheduling P(S)Cell PDSCH or PUSCH Huawei, HiSilicon
R1-2102416 Discussion on cross-carrier scheduling from SCell to PCell OPPO
R1-2102471 Discussion on cross-carrier scheduling from SCell to Pcell Spreadtrum Communications
R1-2102503 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2102544 Discussion on Scell scheduling Pcell vivo
· Proposal 1: Reuse cross-carrier scheduling framework in NR Rel-15 as well as the search space linkage rule to enable Scell scheduling P(S)cell.
· Proposal 2: Indication of ‘other’ in schedulingCellInfo for a P(S)Cell means that the P(S)Cell could be scheduled by itself and another Scell jointly.
· Proposal 3: Dynamic activation/deactivation of scheduling from S-SCell to PCell/PSCell with additional signaling is not supported.
· Proposal 4: Regarding BD/CE budget associated with P(S)cell, the following three options can be considered:
o Option1. a predefined BD/CE budget (B1) that concerns P(S)cell self-scheduling only and another predefined BD/CE budget (B2) that concerns S-Scell scheduling P(S)cell only
o Option2. a predefined total BD/CE budget (B3) that concerns P(S)cell self-scheduling and CCS from S-Scell to P(S)cell, and a semi-static BD/CE budget (B1) for P(S)cell self-scheduling only and another semi-static BD/CE budget (B2) for S-Scell scheduling P(S)cell only, whereas B1 and/or B2 are derived based on Search space configuration. Specifically, there are two alternatives:
§ Alt.2-1. B1 is the maximum number of PDCCH candidates/CCE to be monitored for CSS(s) on a slot/span on P(S)cell, and B2=B3-B1.
§ Alt.2-2. B2 is the maximum number of PDCCH candidates/CCEs to be monitored for CCS from S-Scell to P(S)cell on a slot/span, and B1=B3-B2.
o Option3. a predefined total BD/CE budget (B3) that concerns P(S)cell self-scheduling and CCS from S-Scell to P(S)cell.
· Proposal 5: Regarding overbooking handling, the following two options can be considered:
o Option1. The overbooking process for P(S)cell considerPDCCH candidate/CCE for P(S)cell self-scheduling only
o Option2. The overbooking process for P(S)cell consider PDCCH candidate/CCE for both P(S)cell self-scheduling and PDCCH candidate/CCE for S-Scell scheduling P(S)cell
· Proposal 6: As a mandatory capability when S-Scellll scheduling Pcell is configured,
o UE supports to be configured to monitor DCI formats 0_1/1_1/0_2/1_2 that schedule PDSCH/PUSCH on PCell/PSCell on PCell/PSCell USS set(s), and/or on S-Scell USS set(s) (i.e. Alt 2.1);
o UE monitors PDCCH for scheduling Pcell by separate semi-static BD/CCE budget on Pcell and S-Scell (i.e. option 1 and option 2 in Section 2.2);
o UE supports overbooking of Pcell CSS and Pcell USS for scheduling Pcell.
· Proposal 7: Applicability of DCI 2_5 is the same as in Rel-16, while support DCI 2_6 extension to S-Scell when CCS from S-Scell to P(S)Cell is configured.
· Proposal 8: The monitoring behavior of DCI 0_0/1_0 in USS of P(S)Cell is aligned with that of DCI 0_1/1_1 in USS of P(S)Cell.
· Proposal 9: Whether and how to support S-Scell dormancy should be studied.
· Proposal 10: Whether to allow dormancy indication in S-Scell when it is configured to schedule P(S)cell should be discussed.
Decision: The document is noted.
R1-2102611 Discussion on cross-carrier scheduling from Scell to Pcell CATT
R1-2102684 On Cross-Carrier Scheduling from SCell to PCell/PSCell MediaTek Inc.
R1-2102803 Om cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell
R1-2102902 Discussion on cross-carrier scheduling from SCell to Pcell CMCC
R1-2102968 Discussion on Cross-carrier scheduling from SCell to PCell Xiaomi
R1-2103052 On SCell scheduling PCell transmissions Intel Corporation
R1-2103126 Views on Rel-17 DSS SCell scheduling PCell Apple
R1-2103188 Cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
R1-2103202 Search space monitoring in sSCell and PCell InterDigital, Inc.
R1-2103262 Cross-carrier scheduling from SCell to PCell Samsung
R1-2103333 Cross-carrier scheduling from SCell to Pcell ETRI
R1-2103359 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2103596 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2103609 Cross-carrier scheduling (from Scell to Pcell) Lenovo, Motorola Mobility
R1-2103645 Enhanced cross-carrier scheduling for DSS Ericsson
R1-2103659 Discussion on cross-carrier scheduling from sSCell to PCell/PSCell ASUSTeK
[104b-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion/approval for CCS
- 1st check point: April 15
- 2nd check point: April 20
R1-2103846 Summary of Email discussion [104b-e-NR-DSS-01] Moderator (Ericsson)
Agreement
When CCS from sSCell to PCell/PSCell is configured
· CIF=0 used for sSCell self-scheduling, and CIF for sSCell to PCell cross-carrier scheduling is explicitly configured using RRC signalling
R1-2103943 Summary#2 of Email discussion [104b-e-NR-DSS-01] Moderator (Ericsson)
Agreement
PDCCH overbooking on sSCell USS set(s) is not allowed
R1-2104081 Summary#3 of Email discussion [104b-e-NR-DSS-01] Moderator (Ericsson)
For RAN1#105-e, companies are encouraged to consider:
Further discuss PDCCH monitoring and BD/CCE limit handling in RAN1#105e considering below BD/CCE limit handling options
· Option A
o At least when P(S)Cell SCS is not higher than sSCell SCS, PDCCH monitoring candidates on P(S)Cell and/or sSCell are configured such that max of (x1(m1)+x2(m1))+max of y(m2) corresponding to any P(S)Cell slots m1 and m2 is less than or equal to Z1
o At least the case of Z1 = 44 is supported for P(S)Cell SCS 15kHz
§ FFS if Z1 larger than above can also be supported based on UE capability (e.g. similar to BDFactorR in Rel16)
o FFS signalling details on how the limit Z1 is realized, e.g.
§ RRC configured BD limit/scaling factor-based limit for max(x1(m)+x2(m))
§ Separate RRC configured BD limits/scaling factor-based limits for max(x1(m)+x2(m)) and max(y(m))
§ separate BdfactorR for P(S)Cell and sSCell
§ SS configuration-based BD limit for max(x1(m)+x2(m)) and max(y(m))
§ RRC configured BD limit/scaling factor-based limit for max(x1(m)+x2(m))+ max(y(m))
§ Counting ‘sSCell-to-P(S)Cell’ scheduling as an additional scheduling cell with numerology given by sSCell numerology in determining the BD/CCE limits
o FFS reference SCS to use when P(S)Cell has higher SCS than sSCell (if supported)
o
For sSCell scheduling
P(S)Cell, the UE is not required to monitor on the active DL BWP with SCS configuration µ of the sSCell more than PDCCH candidates per slot of sSCell.
§
FFS how limit is computed and applied when CCS from sSCell to P(S)Cell is
configured
· Option B
o At least when P(S)Cell SCS is not higher than sSCell SCS, For P(S)Cell slot m, PDCCH monitoring candidates on P(S)Cell and/or sSCell are configured such that x1(m)+x2(m)+y(m) is less than or equal to BD limit Z2
o At least the case of Z2 = 44 is supported for P(S)Cell SCS 15kHz
§ FFS if Z2 larger than above can also be supported based on UE capability (e.g. similar to BDFactorR in Rel16)
o
max of (x1(m1)+x2(m1)) +
max of y(m2) corresponding to any P(S)Cell slots m1 and m2 can is
allowed to be larger than BD limit Z2
o FFS signalling details on how the limit Z2 is realized
o FFS reference SCS to use when P(S)Cell has higher SCS than sSCell (if supported)
o
For sSCell scheduling
P(S)Cell, the UE is not required to monitor on the active DL BWP with SCS configuration µ of the sSCell more
than PDCCH candidates per slot of sSCell.
§
FFS how limit is computed and applied when CCS from sSCell to P(S)Cell is
configured
· Option C
o PDCCH monitoring candidates on P(S)Cell are configured such that max of (x1(m1)+x2(m1)) is less than or equal to Z3
§ Z3 is derived by the PDCCH monitoring capability of PCell
o PDCCH monitoring candidates on sSCell are configured such that max of y(m2) is less than or equal to Z4
§ Z4 is derived by the PDCCH monitoring capability of sSCell
o FFS details to define Z3 and Z4, e.g.
§ Separate RRC configured BD limits/scaling factor-based limits for max(x1(m)+x2(m)) and max(y(m))
o For sSCell scheduling P(S)Cell, the UE is not required to monitor on the active DL BWP with SCS configuration µ of the sSCell more than Z4 PDCCH candidates per slot of sSCell
· Note
o x1(m) is #BDs for PDCCH CSS(s) candidates monitored on P(S)Cell slot m
o x2(m) is #BDs for PDCCH USS(s) candidates monitored on P(S)Cell slot m
o y(m) is #BDs for PDCCH USS(s) candidates monitored on sSCell in all sSCell slot(s) that overlap slot m of P(S)Cell
o USS(s) => USS(s) that can schedule PDSCH/PUSCH on P(S)Cell)
Final summary in R1-2104100.
Focusing on study whether or not to support the feature first
Void (not be handled during this e-meeting). No contributions please.
R1-2102310 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2102417 Discussion on efficient activation/de-activation for SCell OPPO
R1-2102472 Discussion on efficient activation/de-activation mechanism for SCells in NR CA Spreadtrum Communications
R1-2102504 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2102545 Discussion on efficient activation/de-activation mechanism for Scells vivo
R1-2102612 Discussion on efficient activation and de-activation mechanism for SCell in NR CA CATT
R1-2102685 Discussion on temporary RS MediaTek Inc.
R1-2102768 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2102804 On low latency Scell activation Nokia, Nokia Shanghai Bell
R1-2102815 Discussion on efficient activation mechanism for SCells NEC
R1-2102903 Discussion on efficient activation/de-activation mechanism for SCells CMCC
R1-2103053 On efficient activation/de-activation for SCells Intel Corporation
R1-2103127 On efficient SCell Activation/Deactivation Apple
R1-2103189 Efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2103203 Fast SCell Activation InterDigital, Inc.
R1-2103263 Reducing Latency for SCell Activation/Deactivation Samsung
R1-2103597 Discussion on efficient activation deactivation mechanism for Scells NTT DOCOMO, INC.
R1-2103646 Reduced Latency SCell Activation Ericsson
R1-2103675 Efficient activation/deactivation of SCell ASUSTEK COMPUTER (SHANGHAI)
[104b-e-NR-DSS-02] – Frank (Huawei)
Email discussion/approval for efficient activation/de-activation mechanism for SCells in NR CA
- 1st check point: April 15
- 2nd check point: April 20
R1-2103885 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2103886 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
Agreement
For efficient activation of SCells
· Option 1a: MAC CE(s) contained in a single PDSCH to trigger both SCell activation and corresponding temporary RS(s)
o Details FFS including timeline design for receiving temporary RS
Note: Separate from the support of Option 1a, it is up to RAN4 whether or not to consider an activation time enhancement for Option 2 without requiring further RAN1 work
· Option 2: A Rel-15/16 SCell activation MAC-CE to trigger SCell activation and a Rel-15/16 DCI to trigger corresponding Rel-15/16 A-TRS(s)
Send an LS to RAN4.
R1-2104109 [Draft] Reply LS on temporary RS for efficient SCell activation in NR CA Huawei
Decision: As per email decision posted on April 21st, the draft LS is endorsed. Final version is approved in R1-2104110.
Void (not be handled during this e-meeting). No contributions please.
Please refer to RP-193260 for detailed scope of the WI
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2)
R1-2106236 Session notes for 8.13 (NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (Samsung)
R1-2104185 On cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell
R1-2104232 Discussion on SCell PDCCH scheduling P(S)Cell PDSCH or PUSCH Huawei, HiSilicon
R1-2104340 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2104391 Discussion on Scell scheduling Pcell vivo
R1-2104445 Discussion on cross-carrier scheduling from SCell to Pcell Spreadtrum Communications
R1-2104495 Discussion on cross-carrier scheduling from Scell to Pcell CATT
R1-2104635 Discussion on cross-carrier scheduling from SCell to Pcell CMCC
R1-2105970 Cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated (rev of R1-2104698)
R1-2104806 Discussion on cross-carrier scheduling from Scell to Pcell OPPO
R1-2104931 On SCell scheduling PCell transmissions Intel Corporation
R1-2105131 Views on Rel-17 DSS SCell scheduling PCell Apple
R1-2105230 Cross-carrier scheduling from SCell to Pcell ETRI
R1-2105339 Cross-carrier scheduling from SCell to PCell Samsung
R1-2105378 On Cross-Carrier Scheduling from SCell to PCell/PSCell MediaTek Inc.
R1-2105401 Search space monitoring in sSCell and PCell InterDigital, Inc.
R1-2105441 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2105546 Discussion on Cross-carrier scheduling from SCell to PCell Xiaomi
R1-2105723 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2105765 Cross-carrier scheduling (from Scell to Pcell) Lenovo, Motorola Mobility
R1-2105796 Enhanced cross-carrier scheduling for DSS Ericsson
R1-2105847 Discussion on cross-carrier scheduling from sSCell to PCell/PSCell ASUSTeK
[105-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion/approval for CCS
· 1st check point: May 24
· 2nd check point: May 27
R1-2106078 Summary of Email discussion [105-e-NR-DSS-01] Moderator (Ericsson)
R1-2106136 Summary#2 of Email discussion [105-e-NR-DSS-01] Moderator (Ericsson)
R1-2106245 Summary#3 of Email discussion [105-e-NR-DSS-01] Moderator (Ericsson)
R1-2106291 Summary#4 of Email discussion [105-e-NR-DSS-01] Moderator (Ericsson)
From GTW sessions:
Agreement
Two types of UEs (Type A and Type B) can support CCS from sSCell to P(S)Cell
· For Type A UE
o At least following search space sets on P(S)Cell and search space sets on sSCell are configured so that the UE does not monitor them in overlapping [slot/symbol] of P(S)Cell and sSCell
§ search space sets on P(S)Cell
· USS sets for DCI formats 0_1,1_1,0_2,1_2 (if supported for Type A UE)
· USS sets for DCI formats 0_0,1_0
· Type3-CSS set(s) for DCI formats 1_0/0_0 with C-RNTI/CS-RNTI/MCS-C-RNTI
§ search space sets on sSCell
· USS set(s) for scheduling P(S)Cell
o FFS: BD/CCE handling
· For Type B UE
o Following search space sets on P(S)Cell and search space sets on sSCell can be configured so that the UE monitors them in overlapping [slot/symbol] of P(S)Cell and sSCell
§ search space sets on P(S)Cell
· USS sets for DCI formats 0_0,1_0
· Type3-CSS set(s) for DCI formats 1_0/0_0 with C-RNTI/CS-RNTI/MCS-C-RNTI
§ search space sets on sSCell
· USS set(s) for scheduling P(S)Cell
o For handling ‘USS sets for scheduling P(S)Cell’ on P(S)Cell and/or on sSCell for DCI formats 0_1,1_1,0_2,1_2
§ Alt 2-1 is adopted
o There is no restriction on Type-0/0A/1/2-CSS sets configurations
o FFS: BD/CCE handling
· For Type A and/or Type B UE
o FFS: switching to ‘normal’ PDCCH monitoring on P(S)Cell when sSCell is deactivated
· FFS: Whether Type A is specified or is Type-B with restrictions (as part of UE features discussion)
· FFS: Whether the UE can be configured with unaligned CA
· FFS: Whether the above applies for multicast PDSCH
Discuss further in RAN1#106-e:
· Proposal 4v3 in R1-2106291
Final summary in R1-2106356.
Focusing on study whether or not to support the feature first
R1-2104186 Way Forward On single DCI scheduling two cells Nokia, Nokia Shanghai Bell
R1-2104233 Discussion on multi-carrier scheduling using single PDCCH Huawei, HiSilicon
R1-2104341 Discussion on Multi-cell PDSCH Scheduling via a Single DCI ZTE
R1-2104392 Discussion on joint scheduling vivo
R1-2104446 Discussion on multi-cell PDSCH scheduling via a single DCI Spreadtrum Communications
R1-2104496 Discussion on multi-cell PDSCH scheduling via a single DCI CATT
R1-2104807 Discussion on multi-cell PDSCH scheduling via a single DCI OPPO
R1-2104868 On multi-cell PDSCH scheduling via a single DCI Lenovo, Motorola Mobility
R1-2104932 On 2-cell scheduling via single DCI Intel Corporation
R1-2105132 Views on Rel-17 DSS Multi-cell PDSCH scheduling via a single DCI Apple
R1-2105340 On a single DCI format scheduling on multiple cells Samsung
R1-2105402 On the support of single DCI scheduling two cells InterDigital, Inc.
R1-2105412 Multi-cell PDSCH scheduling via a single DCI NEC
R1-2105442 Discussion on multi-cell PDSCH scheduling via a single DCI LG Electronics
R1-2105724 Discussion on multi-cell PDSCH scheduling via a single DCI for NR DSS NTT DOCOMO, INC.
R1-2105797 Study on single DCI scheduling PDSCH on multiple cells Ericsson
[105-e-NR-DSS-02] – Haipeng (Lenovo)
Email discussion/approval for multi-cell PDSCH scheduling via a single DCI
· 1st check point: May 24
· 2nd check point: May 27
R1-2106069 Feature lead summary #1 on multi-cell scheduling via a single DCI Haipeng (Lenovo)
Decision: As per email decision posted on May 26th,
Conclusion
Stop the RAN1 work on two-cell PDSCH scheduling via a single DCI for specification support in Rel-17 DSS
Final summary in R1-2106134. No LS sent to RAN, the conclusion shall be duly reported in the WI status report to plenary.
R1-2104187 On low latency Scell activation Nokia, Nokia Shanghai Bell
R1-2104206 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2104234 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2104342 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2104393 Discussion on efficient activation/de-activation mechanism for Scells vivo
R1-2104447 Discussion on efficient activation/de-activation mechanism for SCells in NR CA Spreadtrum Communications
R1-2104497 Discussion on efficient activation and de-activation mechanism for SCell in NR CA CATT
R1-2104699 Efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2104808 Discussion on efficient activation/de-activation for Scell OPPO
R1-2104933 On efficient activation/de-activation for SCells Intel Corporation
R1-2105133 On efficient SCell Activation/Deactivation Apple
R1-2105341 Remaining Issues on Scell Activation/Deactivation Samsung
R1-2105379 Discussion on temporary RS MediaTek Inc.
R1-2105403 Efficient SCell Activation InterDigital, Inc.
R1-2105413 Discussion on efficient activation mechanism for SCells NEC
R1-2105725 Discussion on efficient activation deactivation mechanism for Scells NTT DOCOMO, INC.
R1-2105798 Reduced Latency SCell Activation Ericsson
R1-2105846 Efficient activation/deactivation of SCell ASUSTeK
[105-e-NR-DSS-03] – Frank (Huawei)
Email discussion/approval for efficient activation/de-activation mechanism
· 1st check point: May 24
· 2nd check point: May 27
R1-2106147 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From GTW session:
Agreement
For efficient activation of Scells, the triggered temporary RS is aperiodic.
Agreement
For efficient activation of a Scell (in known Scell case), at least the number of temporary RS bursts is indicated by a field in new MAC-CE
· The number of temporary RS bursts is RRC configurable.
· FFS: which field in MAC-CE is used and how this field is associated with the number of bursts
· For the purpose of designing temporary RS Scell activation, there is no RAN1 specification impact for the case where the number of indicated temporary RS bursts is smaller than what is expected by the UE
R1-2106148 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From GTW session:
Agreement
To trigger temporary RS for efficient activation of SCells, the contents of the triggering MAC-CE(s) in a single PDSCH provide at least the following information (explicitly or implicitly):
· Whether or not temporary RS is triggered
· FFS detailed Information of temporary RS, e.g.:
o Resources used for triggered Temporary RS
o Triggering time offset of triggered Temporary RS
o QCL source for triggered Temporary RS
· FFS: Detailed signalling structure of the triggering MAC-CE(s) including the down-selection between the following example options and whether the decision should be made in RAN1 or RAN2
o Opt. 1.1: One new MAC CE for both SCell activation triggering and corresponding temporary RS triggering
o Opt. 1.2: One R15/16 SCell activation MAC CE for SCell activation triggering and one new MAC CE (in the same PDSCH) for corresponding temporary RS triggering
Agreement
For efficient activation of a Scell (in known Scell case), the triggering offset of temporary RS is indicated by a field in new MAC-CE
· The candidate value(s) of triggering offset(s) is RRC configurable
· FFS: which field in MAC-CE is used and how this field is associated with the value of triggering offset
Agreement
For the reference slot for triggering offset of temporary RS
· Option 2: the last DL slot of the to-be-activated Scell overlapping with slot n+k as defined in 38.213 sub-clause 4.3
· FFS: the earliest slot no earlier than the reference slot for a UE to receive a triggered temporary RS
Agreement
If a UE measures a temporary RS triggered by a MAC-CE during SCell activation procedure, the measurement is performed within the BWP bandwidth of BWP indicated by firstActiveDownlinkBWP-Id
Final summary in R1-2106327.
R1-2104394 Discussion on other aspects on DSS vivo
R1-2104498 Simulation results for multi-cell PDSCH scheduling via a single DCI CATT
R1-2104577 Further analysis and simulation for Multi-cell scheduling for both downlink and uplink ZTE
R1-2105519 Remaining issues on the efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2105799 CRS Rate-matching enhancement for DSS Ericsson
Please refer to RP-211345 for detailed scope of the WI
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2)
R1-2108611 Session notes for 8.13 (NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC)
R1-2108003 Work plan for Rel17 WI on NR Dynamic spectrum sharing (DSS) Ericsson
R1-2106472 Discussion on SCell PDCCH scheduling P(S)Cell PDSCH or PUSCH Huawei, HiSilicon
R1-2106627 Discussion on Scell scheduling Pcell vivo
R1-2106721 Discussion on cross-carrier scheduling from SCell to Pcell Spreadtrum Communications
R1-2106749 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2106915 Cross-carrier scheduling from SCell to PCell Samsung
R1-2107187 Cross-carrier scheduling (from Scell to Pcell) Lenovo, Motorola Mobility
R1-2107277 Discussion on cross-carrier scheduling from Scell to Pcell OPPO
R1-2107372 Cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
R1-2107428 Discussion on cross-carrier scheduling from SCell to Pcell CMCC
R1-2107460 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2107483 Cross-carrier scheduling from SCell to PCell ETRI
R1-2107499 On Cross-Carrier Scheduling from sSCell to P(S)Cell MediaTek Inc.
R1-2107526 On cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell
R1-2107614 On SCell scheduling PCell transmissions Intel Corporation
R1-2107641 PCell and sSCell scheduling Pcell InterDigital, Inc.
R1-2107766 Views on Rel-17 DSS SCell scheduling PCell Apple
R1-2107884 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2107903 Discussion on Cross-carrier scheduling from SCell to PCell Xiaomi
R1-2108004 Enhanced cross-carrier scheduling for DSS Ericsson
[106-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion/approval for CCS
R1-2108307 Summary of Email discussion [106-e-NR-DSS-01] Moderator (Ericsson)
From GTW session:
Agreement
Specification supports dormant BWP operation on sSCell for a UE is configured CCS from sSCell to P(S)Cell.
Agreement
· When CCS from sSCell to P(S)Cell is configured for a UE
o at least the number of PDCCH monitoring candidates monitored on sSCell (for scheduling P(S)Cell) is indicated to the UE using the SS set linking approach as in Rel16
o
FFS: If any
modifications to Rel16 approach are introduced for monitoringSlotPeriodicityAndOffset, monitoringSymbolsWithinSlot,
duration for the PDCCH monitoring candidates
monitored on sSCell (for scheduling P(S)Cell)
R1-2108354 Summary#2 of Email discussion [106-e-NR-DSS-01] Moderator (Ericsson)
R1-2108476 Summary#3 of Email discussion [106-e-NR-DSS-01] Moderator (Ericsson)
From GTW session:
Agreement
·
At least for Type B UE,
when the UE is configured for CCS from sSCell to P(S)Cell and when P(S)Cell SCS (
) is less than or equal to sSCell SCS (
), and at least when UE is not provided
monitoringCapabilityConfig for any cell, down select one from [based on Option
A/C] or [based Option C] below
o [based on Option A/C]
§ On P(S)Cell (for self-scheduling)
·
UE is not required to
monitor more than 
PDCCH BD candidates per P(S)Cell slot
§ On sSCell (for cross-carrier scheduling to P(S)Cell)
·
UE is not required to
monitor more than [
or 
] PDCCH BD candidates per sSCell slot (Note: this is assumed per
Rel16)
·
UE is additionally not
required to monitor more than 
PDCCH BD candidates per P(S)Cell slot
and
are based on RRC configuration and at least cases of 
are supported
§ FFS the following for [based on Option A/C]
· Distribution of PDCCH BD candidates between multiple sSCell slots overlapping a P(S)Cell slot including whether the above additional BD limitation is defined per sSCell slot or per P(S)Cell slot.
o Discuss further using following alternatives as starting point (other alternatives/further refinement of alternatives not precluded)
§ Alt1
·
The additional BD
limitation is per sSCell slot with further limitation that UE is not required
to monitor more than 
PDCCH BD candidates per sSCell slot
§ Alt 2
· The additional BD limitation is per P(S)Cell slot and no further restrictions
§ Alt 3
· The additional BD limitation is per P(S)SCell slot with below further limitation
o All search space configurations monitored on sSCell for cross-carrier scheduling to P(S)Cell are within a single span of 3 consecutive OFDM symbols within a duration spanning P(S)Cell slot
·
Whether/how the definition
of 
or
is modified compared to Rel16 when UE is configured with CCS from
sSCell to P(S)Cell
·
Whether separate 
and 
are configured by RRC or if 
and only is configured
o [based on Option C]
§ On P(S)Cell (for self-scheduling)
·
UE is not required to
monitor more than 
PDCCH BD candidates per P(S)Cell slot
§ On sSCell (for cross-carrier scheduling to P(S)Cell)
·
UE is not required to
monitor more than 
PDCCH BD candidates per sSCell slot
§
When determining and
· P(S)Cell self-scheduling is counted by applying scaling factor s1,
· sSCell to PCell scheduling is counted additionally (assuming SCS of sSCell) by applying scaling factor s2
and 
§ FFS the following
· Allowed combinations of s1 and s2 , and whether they are fixed or configured via RRC
·
Whether/how the definition
of or is modified compared to Rel16 when UE is configured with CCS from
sSCell to P(S)Cell
· FFS the following
o Multi-TRP handling
o PDCCH BD handling when monitoringCapabilityConfig = r16monitoringcapability is configured for any cell
Agreement
· Endorse below TP to 38.300 from RAN1 perspective
· Send LS to RAN2 with the TP and list of RAN1 agreements, to update Stage 2 spec are needed to reflect the RAN1 agreements
----------------------------------------- start TP1 for 38.300 v.xyz -------------------------------------------
10.8 Cross Carrier Scheduling
Cross-carrier scheduling with the Carrier Indicator Field (CIF) allows the PDCCH of a serving cell to schedule resources on another serving cell but with the following restrictions:
- Cross-carrier scheduling does not
apply to Pcell i.e. When cross-carrier scheduling from an SCell to Pcell is not
configured, Pcell
can only be is always scheduled via
its PDCCH;
- When cross-carrier scheduling from an SCell to Pcell is configured, PDCCH on that SCell can schedule Pcell’s PDSCH and PUSCH, and PDCCH on the Pcell can also schedule Pcell’s PDSCH and PUSCH, and PDCCH on Pcell cannot schedule PDSCH and PUSCH on any other cell. Only one SCell can be configured to be used for cross-carrier scheduling to Pcell;
- When an SCell is configured with a PDCCH, that cell’s PDSCH and PUSCH are always scheduled by the PDCCH on this SCell;
- When an SCell is not configured with a PDCCH, that SCell’s PDSCH and PUSCH are always scheduled by a PDCCH on another serving cell;
- The scheduling PDCCH and the scheduled PDSCH/PUSCH can use the same or different numerologies.
--------------------------------------------------- end TP1 -----------------------------------------------
R1-2108575 Summary#4 of Email discussion [106-e-NR-DSS-01] Moderator (Ericsson)
R1-2108661 Summary#5 of Email discussion [106-e-NR-DSS-01] Moderator (Ericsson)
R1-2108576 Draft LS on Cross-carrier scheduling from SCell to P(S)Cell Moderator (Ericsson)
Decision: As per email decision posted on Aug 31st, the draft LS is endorsed. Final LS is approved in R1-2108662.
R1-2106473 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2106628 Discussion on efficient activation/de-activation mechanism for Scells vivo
R1-2106722 Discussion on efficient activationde-activation mechanism for SCells in NR CA Spreadtrum Communications
R1-2106750 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2106916 Remaining Issues on Scell Activation/Deactivation Samsung
R1-2107086 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2107278 Discussion on efficient activation/de-activation for Scell OPPO
R1-2107373 Efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2107527 On low latency Scell activation Nokia, Nokia Shanghai Bell
R1-2107615 On efficient activation/de-activation for SCells Intel Corporation
R1-2107642 Fast SCell Activation InterDigital, Inc.
R1-2107767 On Efficient SCell Activation/Deactivation Apple
R1-2107885 Discussion on efficient activation deactivation mechanism for SCells NTT DOCOMO, INC.
R1-2107904 Discussion on efficient activation and de-activation mechanism for SCell in NR CA Xiaomi
R1-2108005 Reduced Latency SCell Activation Ericsson
R1-2108047 Efficient activation/deactivation of SCell ASUSTeK
[106-e-NR-DSS-02] – Frank (Huawei)
Email discussion/approval for efficient activation/de-activation mechanism
R1-2108317 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2108318 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From GTW session:
Agreement
For efficient SCell activation, the earliest slot for a UE to receive a triggered temporary RS is the reference slot (i.e., the last DL slot of the to-be-activated Scell overlapping with slot n+k as defined in 38.213 sub-clause 4.3).
Conclusion
For the purpose of designing temporary RS for Scell activation, RAN1 will not discuss for the case where a gNB may assume the to-be-activated SCell with assistance of temporary RS is a known SCell for a UE but it is actually unknown SCell from the UE side during the SCell activation duration.
Agreement
For to-be-activated SCell, if any BWP ID is configured as part of temporary RS(s) configuration, the value of the BWP ID is expected to be equal to firstActiveDownlinkBWP-Id;
R1-2108380 Summary#3 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2108381 Summary#4 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From GTW session:
Agreement
To trigger temporary RS,
· MAC-CE at least provides the following information:
o temporary RSs are to be triggered on X out of Y (Y≥X) to-be-activated SCells, respectively, while no temporary RS is to be triggered on the other to-be-activated SCells.
· The following information can be provided by RRC for temporary RS for each SCell
o The number of RS bursts and the gap length between the RS bursts (Opt 2.3.3)
o Triggering offset of temporary RS (Opt 2.3.4)
§ Triggering offset can be provided, e.g., by
reusing existing CSI-RS framework
o QCL information (Opt 2.3.5)
§ Triggering QCL information can be provided,
e.g., by reusing existing CSI-RS framework
o A unique temporary RS configuration index
o FFS: the maximum
number of temporary RS per cell/per UE
Note: Reusing A-TRS triggering framework is not precluded.
· Information for 0, 1, or more temporary RS can be provided for each configured SCell
Agreement
· For triggering temporary RS, down-select based on the following alternatives, or let RAN2 be aware the status of this discussion
o
Alt 1: Bitmap approach in
MAC-CE similar to SCell activation
§ Every Z-bit block in the bitmap corresponds to a SCell, Z>=0
§ A Z-bit block indicates the temporary RS [configuration index], and a value zero indicated by the bit block means no RS resource transmitted.
§ The to-be-activated SCell is indicated via the C values in the legacy SCell activation/de-activation MAC CE or in the new MAC-CE
o Alt 2: Reuse A-TRS triggering framework
§ A trigger state is indicated by the MAC-CE explicitly
§
The association between a
trigger state and aperiodic temporary RS for one or multiple SCells is
configured by RRC according Rel-16 A-TRS triggering
framework
·
SCell ID is
configured as a part of the temporary RS configuration. Some SCell IDs derived
from the trigger state triggered by the new MAC-CE may not refer to
to-be-activated SCells that are indicated by the new MAC-CE or the legacy SCell
activation/de-activation MAC-CE
§ FFS: The value zero of the MAC-CE indication means no temporary RS is triggered by the MAC-CE for all to-be-activated SCells
o Note: The down-selection targets at a RAN1 consensus on MAC-CE functionality and the list of RRC parameters for this feature. Any MAC-CE signaling design above are reference concept, its final MAC-CE signaling design is up to RAN2.
Final summary in:
R1-2108668 Summary#5 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2106751 Considerations on potential further enhancements for CA ZTE
R1-2107671 Remaining issues on the efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2108006 CRS Rate-matching enhancement for DSS Ericsson
Please refer to RP-211345 for detailed scope of the WI.
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2).
Incoming LS(s) related to this work/study item under agenda item 5: R1-2108708.
R1-2110620 Session notes for 8.13 (NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC)
[106bis-e-R17-RRC-DSS] – Ravi (Ericsson)
Email discussion on Rel-17 RRC parameters for DSS
- 1st check point: October 14
- Final check point: October 19
R1-2110665 Summary of Email discussion [106bis-e-R17-RRC-DSS] Moderator (Ericsson)
Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].
For the editors: The table (excel file in R1-2110665) is endorsed in principle. Please consider them during drafting the specification.
[106bis-e-R17-RRC-NR-DC] – Frank (Huawei)
Email discussion on Rel-17 RRC parameters for LTE_NR_DC_enh2
- 1st check point: October 14
- Final check point: October 19
No stable RRC list to be agreed this meeting
R1-2108773 Discussion on SCell PDCCH scheduling P(S)Cell PDSCH or PUSCH Huawei, HiSilicon
R1-2108855 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2108929 Discussion on cross-carrier scheduling from SCell to Pcell Spreadtrum Communications
R1-2109005 Discussion on Scell scheduling Pcell vivo
R1-2109098 Discussion on cross-carrier scheduling from Scell to Pcell OPPO
R1-2109306 Discussion on cross-carrier scheduling from SCell to Pcell CMCC
R1-2109390 Discussion on cross-carrier scheduling from SCell to PCell Xiaomi
R1-2109518 Cross-carrier scheduling from SCell to PCell Samsung
R1-2109551 On Cross-Carrier Scheduling from sSCell to P(S)Cell MediaTek Inc.
R1-2109636 On SCell scheduling PCell transmissions Intel Corporation
R1-2109704 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2109820 Discussion on cross-carrier scheduling from SCell to Pcell ETRI
R1-2109895 Discussion on cross carrier scheduling from sSCell to PCell InterDigital, Inc.
R1-2109938 Cross-carrier scheduling (from Scell to Pcell) Lenovo, Motorola Mobility
R1-2109987 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2110059 Views on Rel-17 DSS SCell scheduling PCell Apple
R1-2110141 Enhanced cross-carrier scheduling for DSS Ericsson
R1-2110213 Cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
R1-2110376 On cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell (rev of R1-2110294)
[106bis-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion/approval for CCS
- 1st check point: October 14
- Final check point: October 19
R1-2110452 Summary of Email discussion [106bis-e-NR-DSS-01] Moderator (Ericsson)
From Oct 12th GTW session
Discussion Point
· Companies are encouraged to provide their view on the following on how to proceed for Type A UE
o Possible Approach 1
§ All UEs (supporting cross-carrier scheduling from SCell to PCell) can simultaneously monitor ‘USS sets (for P(S)Cell scheduling) on sSCell’ and ‘Type 0/0A/1/2/CSS sets on P(S)Cell at least for broadcast DCI formats’
§ BD/CCE limits for Type B UEs are applicable for all UEs
§ Separate UE capability/incapability is introduced to indicate support/no support of simultaneous monitoring of ‘USS sets (for P(S)Cell scheduling) on sSCell’ and ‘Type 0/0A/1/2/CSS sets on P(S)Cell for unicast DCI formats’
o Possible Approach 2
§ All UEs (supporting cross-carrier scheduling from SCell to PCell) can be configured with Type 0/0A/1/2/CSS sets on P(S)Cell that overlap with sSCell USS sets (for P(S)Cell scheduling)
§ Type A UEs drop the USS set(s) on sSCell (for P(S)Cell scheduling) that overlap in same [symbol/slot] as Type 0/0A/1/2/CSS sets on P(S)Cell
· Separate UE capability is introduced for the Type A UEs
§ BD/CCE limit for Type A UE is based on one of the following approaches
· Option B (discussed earlier for Type B UEs)
· Option D
o In a slot, if the PDCCH candidates are only configured on P(S)Cell, the BD/CCE limit on this slot is determined based on the P(S)Cell configurations
o In a slot, if the PDCCH candidates are configured only on sSCell, the BD/CCE limit on this slot is determined based on the sSCell configurations
o The limit of Rel-16 UE capability is applied without further restrictions
· Option E
o
No per-slot change in 
and 
o Discuss further the following (this related to “…DCI formats 0_1,1_1,0_2,1_2 (if supported for Type A UE)..” part in RAN1#105e agreement and the WA from RAN1#104-e)
§ For Possible Approach 1
· Whether UEs not supporting simultaneous monitoring of ‘Type 0/0A/1/2/CSS sets on P(S)Cell for unicast DCIs’ and ‘USS sets (for P(S)Cell scheduling) on sSCell’ support monitoring of non-fallback USS on P(S)Cell when configured for SCell to P(S)cell scheduling
§ For Possible Approach 2
· Whether Type A UEs support monitoring of non-fallback USS on P(S)Cell when configured for SCell to P(S)cell scheduling
o Note
§ ‘broadcast DCI formats’ implies DCI format(s) on Type 0/0A/1/2/CSS with CRC not scrambled by C-RNTI/MCS-C-RNTI/CS-RNTI
§ ‘unicast DCI formats’ implies DCI format(s) on Type 0/0A/1/2/CSS with CRC scrambled by C-RNTI/MCS-C-RNTI/CS-RNTI
R1-2110507 Summary#2 of Email discussion [106bis-e-NR-DSS-01] Moderator (Ericsson)
R1-2110557 Summary#3 of Email discussion [106bis-e-NR-DSS-01] Moderator (Ericsson)
From Oct 18th GTW session
Agreement
Option A is supported in Rel-17
) is less than or equal to sSCell SCS (
),[and at least when UE is not provided
monitoringCapabilityConfig for any cell]§ On P(S)Cell (for self-scheduling)
· UE is not required to monitor more than 
PDCCH BD candidates per P(S)Cell slot
§ On sSCell (for cross-carrier scheduling to P(S)Cell)
·
UE is not required to
monitor more than [
or 
] PDCCH BD candidates per sSCell slot
· UE is additionally not required to monitor more
than 
PDCCH BD candidates per P(S)Cell slot
is based on RRC configuration
is used for P(S)Cell overbooking procedure
§
When determining 
and 
· P(S)Cell self-scheduling is counted by applying scaling factor s1
· sSCell to P(S)Cell scheduling is counted additionally (assuming SCS of sSCell) by applying scaling factor s2
· s1=1 and s2=0, FFS other s1 and s2
· 
and 
are based on RRC configuration
) for BD and CCE limits.·
When P(S)Cell SCS () is larger than sSCell SCS (), for CCS from sSCell to P(S)Cell and, it is not supported Rel-17 DSS.
Decision: As per email decision posted on Oct 20th,
Conclusion
· When sSCell to PCell cross-carrier scheduling is configured, DCI format 2_6 (if configured) is monitored only on P(S)Cell
Working Assumption
· When CIF for sSCell to PCell cross-carrier scheduling is configured, non-fallback DCI formats on P(S)Cell include same number of CIF bits as the corresponding non-fallback DCI formats on sSCell that are used for sSCell to P(S)Cell scheduling
Conclusion
· A UE configured for cross-carrier scheduling from SCell to P(S)Cell can also be configured with unaligned CA (i.e., using ca-SlotOffset ), and a non-zero value for ca-SlotOffset can be configured at least for SCells other than the sSCell
o FFS: Whether case when sSCell is configured with non-zero ca-SlotOffset is supported and any associated capability signalling
· Note: No additional L1 spec impact related to ca-SlotOffset had been identified
Conclusion
· When CCS from sSCell to P(S)Cell is configured for a UE
o monitoringSlotPeriodicityAndOffset, monitoringSymbolsWithinSlot, duration for the PDCCH monitoring candidates monitored on sSCell as determined per Rel16 SS linking approach
Final summary in R1-2110664.
R1-2108774 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2108797 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2108856 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2108930 Discussion on efficient activation de-activation mechanism for SCells in NR CA Spreadtrum Communications
R1-2109006 Discussion on efficient activation/de-activation mechanism for Scells vivo
R1-2109099 Discussion on efficient activation/de-activation for Scell OPPO
R1-2109391 Discussion on efficient activation and de-activation mechanism for SCell in NR CA Xiaomi
R1-2109519 Remaining Issues on Scell Activation/Deactivation Samsung
R1-2109637 On efficient activation/de-activation for SCells Intel Corporation
R1-2109705 Discussion on efficient activation deactivation mechanism for Scells NTT DOCOMO, INC.
R1-2109896 Discussion on fast SCell activation/deactivation InterDigital, Inc.
R1-2109988 Discussion on fast and efficient SCell activation in NR CA LG Electronics
R1-2110060 On efficient SCell Activation/Deactivation Apple
R1-2110129 Efficient activation/deactivation of SCell ASUSTeK
R1-2110142 Reduced Latency SCell Activation Ericsson
R1-2110214 Efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2110295 On low latency Scell activation Nokia, Nokia Shanghai Bell
[106bis-e-NR-DSS-02] – Frank (Huawei)
Email discussion/approval for efficient activation/de-activation mechanism
- 1st check point: October 14
- Final check point: October 19
R1-2110490 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From Oct 14th GTW session
Agreement
· Provide the functionality to be fulfilled, as well as the status about the understanding on Alt 1 and Alt 2, which could be provided by examples (including respective possible RRC parameters, if agreed, required by Alt 1 and Alt 2) to facilitate RAN2’ understanding.
· Send LS to ask RAN2 to consider the following alternatives and finalize the MAC-CE or RRC signalling design, including parameters.
· RAN1 only needs to focus on RRC parameters examples, if needed.
·
List of RAN1
endorsed RRC parameters for this issue will not be sent to RAN2
· Alt 1: Bitmap approach in MAC-CE
o Every Z-bit block in the bitmap corresponds to a SCell, Z>=0
o A Z-bit block indicates the temporary RS [configuration index], and a value zero indicated by the bit block means no RS resource transmitted.
o The to-be-activated SCell is indicated via the C values in the legacy SCell activation/de-activation MAC CE or in the new MAC-CE
· Alt 2: Reuse A-TRS triggering framework
o A trigger state is indicated by the MAC-CE explicitly
o The association between a trigger state and temporary RS for one or multiple SCells is configured by RRC according Rel-16 A-TRS triggering framework
o FFS: The value zero of the MAC-CE indication means no temporary RS is triggered by the MAC-CE for all to-be-activated SCells
R1-2110491 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2110658 Draft LS on triggering signalling of temporary RS for SCell activation Moderator (Huawei)
Note: The draft LS did not proceed due to corresponding RRC parameter list was not stable.
Decision: As per email decision posted on Oct 22nd,
Agreement
The detailed signaling structure of the triggering MAC-CE(s) including the down-selection between the following options is left to RAN2 to decide:
· Opt. 1: One new MAC CE for both SCell activation triggering and corresponding temporary RS triggering
· Opt. 2: One R15/16 SCell activation MAC CE for SCell activation triggering and one new MAC CE (in the same PDSCH) for corresponding temporary RS triggering
Agreement
If two temporary RS bursts are configured, both bursts share the same antenna port index, OFDM symbol location and PRB location of CSI-RS resources in a slot or CSI-RS resources in two consecutive slots.
Final summary in
R1-2110657 Summary#4 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2110697 Summary of agreements for Rel-17 feMR-DC WI WI rapporteur (Huawei)
R1-2109007 Discussion on other aspects for DSS vivo
R1-2109392 Discussion on collision between temporary RS and other signalings Xiaomi
R1-2109757 Remaining issues on the efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2110143 CRS Rate-matching and PDCCH enhancement for DSS Ericsson
Please refer to RP-211345 for detailed scope of the WI.
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2).
R1-2112798 Session notes for 8.13 (NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC)
Rel-17 CRs related to NR DSS
R1-2112441 Introduction of dynamic spectrum sharing enhancements in NR Samsung
Decision: Draft CR to 38.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112479 Introduction of NR further Multi-RAT Dual-Connectivity enhancements Nokia
Decision: Draft CR to 38.214 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
[107-e-R17-RRC-DSS] – Ravi (Ericsson)
Email discussion on Rel-17 RRC parameters for DSS
- Email discussion to start on November 15
R1-2112885 Summary of Email discussion [107-e-R17-RRC-DSS] Moderator (Ericsson)
Decision: As per email decision posted on Nov 21st,
Agreement
Following update is made compared to previous version submitted in R1-2110665:
· Added new row to capture RRC details for parameter α agreed for Option A BD/CCE handling.
[107-e-R17-RRC-NR-DC] – Frank (Huawei)
Email discussion on Rel-17 RRC parameters for LTE_NR_DC_enh2
- Email discussion to start on November 15
R1-2112980 Summary of email discussion [107-e-R17-RRC-NR-DC] on efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
Document is noted. For consolidation under 8 in [107-e-R17-RRC].
R1-2112981 Summary of LS on triggering signaling of temporary RS Moderator (Huawei)
From post-meeting
R1-2112982 Draft LS on triggering signalling of temporary RS for SCell activation Moderator (Huawei)
Decision: As per email decision posted on Dec 3rd, the draft LS to RAN2 including the two alternatives on higher signaling design (as captured in attached excel file) is endorsed. Final LS is approved in R1-2112983.
R1-2112896 Summary of RAN1 agreements for Rel17 NR DSS WI WI rapporteur (Ericsson)
R1-2112904 Summary of agreements for Rel-17 feMR-DC WI WI rapporteur (Huawei)
R1-2110796 Discussion on SCell PDCCH scheduling P(S)Cell PDSCH or PUSCH Huawei, HiSilicon
R1-2110924 Discussion on Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2110944 On cross-carrier scheduling from SCell to Pcell Nokia, Nokia Shanghai Bell
R1-2111043 Remaining issues on Scell scheduling Pcell vivo
R1-2111116 Discussion on cross-carrier scheduling from SCell to Pcell Spreadtrum Communications
R1-2111346 Discussion on cross-carrier scheduling from Scell to Pcell OPPO
R1-2111519 On SCell scheduling PCell transmissions Intel Corporation
R1-2111553 Discussion on cross-carrier scheduling from SCell to PCell Xiaomi
R1-2111631 Discussion on cross-carrier scheduling from SCell to PCell CMCC
R1-2111764 Cross-carrier scheduling from SCell to PCell Samsung
R1-2111900 Views on Rel-17 DSS SCell scheduling Pcell Apple
R1-2111954 Cross-carrier scheduling (from Scell to Pcell) Lenovo, Motorola Mobility
R1-2111999 Remaining issues on cross-carrier scheduling from SCell to Pcell ETRI
R1-2112067 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
R1-2112131 Discussion on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2112154 Enhanced cross-carrier scheduling for DSS Ericsson
R1-2112242 Cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
R1-2112295 On Cross-Carrier Scheduling from sSCell to P(S)Cell MediaTek Inc.
[107-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion/approval for CCS
- 1st check point: November 15
- Final check point: November 19
R1-2112529 Summary of Email discussion [107-e-NR-DSS-01] Moderator (Ericsson)
From Nov 11th GTW session
Proposal
No additional capability of type A UE
Down-select from following approaches for PDCCH monitoring and BD limit handling for Type A UE
· Possible Approach 1
o BD/CCE limits for Type B UEs are applicable for all UEs supporting cross-carrier scheduling from sSCell to P(S)Cell
o Additional simplifications to PDCCH monitoring can be discussed during UE capabilities discussions including the following
§ Type A UE As per RAN1#105-e agreement and
· simultaneous monitoring of ‘USS sets (for P(S)Cell scheduling) on sSCell’ and ‘Type 0/0A/1/2/CSS sets on P(S)Cell’
§ Type A UE As per RAN1#105-e agreement and
· no simultaneous monitoring between ‘USS sets (for P(S)Cell scheduling) on sSCell’ and ‘Type 0/0A/1/2/CSS sets on P(S)Cell for DCI formats with CRC scrambled by C-RNTI/MCS-C-RNTI/CS-RNTI’
· simultaneous monitoring of ‘USS sets (for P(S)Cell scheduling) on sSCell’ and ‘Type 0/0A/1/2/CSS sets on P(S)Cell for DCI formats with CRC not scrambled by C-RNTI/MCS-C-RNTI/CS-RNTI’
· Possible Approach 2
o All UEs (supporting cross-carrier scheduling from SCell to Pcell) can be configured with Type 0/0A/1/2/CSS sets on P(S)Cell that overlap with sSCell USS sets (for P(S)Cell scheduling)
o Type A UEs drop the USS set(s) on sSCell (for P(S)Cell scheduling) that overlap in same [symbol/slot] as Type 0/0A/1/2/CSS sets on P(S)Cell
§ Separate UE capability is introduced for the Type A UEs
o BD/CCE limit for Type A UE is based on one of the following approaches (selected in RAN1#107-e)
§ Option B (discussed earlier for Type B UEs)
§ Option D
· In a slot, if the PDCCH candidates are only configured on P(S)Cell, the BD/CCE limit on this slot is determined based on the P(S)Cell configurations
· In a slot, if the PDCCH candidates are configured only on sSCell, the BD/CCE limit on this slot is determined based on the sSCell configurations
· The limit of Rel-16 UE capability is applied without further restrictions
§ Option E
·
No per-slot change in 
and 
R1-2112619 Summary#2 of Email discussion [107-e-NR-DSS-01] Moderator (Ericsson)
R1-2112653 Summary#3 of Email discussion [107-e-NR-DSS-01] Moderator (Ericsson)
From Nov 17th GTW session
Agreement
If no additional set of (s1, s2) is introduced,
· For Option A BD/CCE limit handling and (s1=1, s2=0) agreed in RAN1#106bis-e,
o On sSCell (for cross-carrier scheduling to P(S)Cell)
§
UE is not required to
monitor more than 
PDCCH BD candidates per sSCell slot
Agreement
BD/CCE limits for Type B UEs are applicable for Type A UEs supporting cross-carrier scheduling from sSCell to P(S)Cell.
Agreement
Confirm the WA from RAN1#106bis-e with addition of below Note (shown in blue)
Working Assumption
· When CIF for sSCell to Pcell cross-carrier scheduling is configured, non-fallback DCI formats on P(S)Cell include same number of CIF bits as the corresponding non-fallback DCI formats on sSCell that are used for sSCell to P(S)Cell scheduling
· Note: per RAN1#102-e agreement, when sSCell to P(S)Cell scheduling is configured for the UE, cross-carrier scheduling from P(S)Cell to another cell is not allowed. The CIF bits included in non-fallback DCI formats on P(S)Cell are considered reserved.
Agreement
When CCS from sSCell to P(S)Cell is configured for the UE,
· Multiple CORESET pools are not configured for PDCCH monitoring on P(S)Cell and not configured for PDCCH monitoring on sSCell;
· Other Scells can be configured with multiple CORESET pools
Agreement
For Option A BD/CCE limit handling agreed in RAN1#106bis-e
·
Value of parameter 
for BD limit handling is configured via RRC from a set of
o 8 possible values
Agreement
For Option A BD/CCE limit handling agreed in RAN1#106bis-e
· For CCE limit handling (i.e., scaling of maximum number of non-overlapping CCEs)
o
same parameter agreed for BD limit handling is used
R1-2112733 Summary#4 of Email discussion [107-e-NR-DSS-01] Moderator (Ericsson)
Decision: As per email decision posted on Nov 19th,
Agreement
When CCS from sSCell to P(S)Cell is configured for the UE,
· r16monitoringcapability is not configured for PDCCH monitoring on P(S)Cell and not configured for PDCCH monitoring on sSCell;
· r16monitoringcapability can be configured for PDCCH monitoring on Scells other than sSCell.
Final summary in R1-2112884.
R1-2110797 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2110884 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2110925 Discussion on Support Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2110945 On low latency Scell activation Nokia, Nokia Shanghai Bell
R1-2111044 Remaining issues on efficient activation/de-activation mechanism for Scells vivo
R1-2111347 Discussion on efficient activation/de-activation for Scell OPPO
R1-2111520 On efficient activation/de-activation for SCells Intel Corporation
R1-2111554 Discussion on efficient activation and de-activation mechanism for SCell in NR CA Xiaomi
R1-2111765 Remaining Issues on Scell Activation/Deactivation Samsung
R1-2111901 On efficient SCell Activation/Deactivation Apple
R1-2112068 Discussion on fast and efficient SCell activation in NR CA LG Electronics
R1-2112132 Discussion on efficient activation deactivation mechanism for Scells NTT DOCOMO, INC.
R1-2112155 Reduced Latency SCell Activation Ericsson
R1-2112243 Efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2112904 Summary of agreements for Rel-17 feMR-DC WI WI rapporteur (Huawei)
[107-e-NR-DSS-02] – Frank (Huawei)
Email discussion/approval for efficient activation/de-activation mechanism
- 1st check point: November 15
- Final check point: November 19
R1-2112605 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From Nov 15th GTW session
Agreement
The max number of NZP CSI-RS resource set configurations for temporary RS per serving cell is the same as current maxNrofNZP-CSI-RS-ResourceSetsPerConfig.
Agreement
For
efficient SCell activation with assistance of temporary RS, a SSB P-TRS of
the to-be-activated SCell is to be configured as a QCL source for the temporary
RS in case of known SCell same as existing specification.
· Note: a SSB of the to-be-activated SCell is a QCL source for the P-TRS per existing specification
· Note: It is RAN1 understanding that Scell activation latency can be reduced compared to Rel-16 even when P-TRS is configured as QCL source for the temporary RS in case of known SCell
Below Working Assumption does not need to be confirmed.
Working Assumption
For efficient SCell activation with assistance of temporary RS, a SSB of the to-be-activated SCell can be indicated as a QCL source for the temporary RS in case of known SCell
· FFS: QCL type
· FFS: the case of unknown SCell
· FFS: other QCL source, e.g. the SSB/P-TRS of another active cell
Agreement(for reference during the discussion)
· For triggering temporary RS, down-select based on the following alternatives, or let RAN2 be aware the status of this discussion
o
Alt 1: Bitmap approach in
MAC-CE similar to SCell activation
§ Every Z-bit block in the bitmap corresponds to a SCell, Z>=0
§ A Z-bit block indicates the temporary RS [configuration index], and a value zero indicated by the bit block means no RS resource transmitted.
§ The to-be-activated SCell is indicated via the C values in the legacy SCell activation/de-activation MAC CE or in the new MAC-CE
o Alt 2: Reuse A-TRS triggering framework
§ A trigger state is indicated by the MAC-CE explicitly
§
The association between a
trigger state and aperiodic temporary RS for one or multiple SCells is
configured by RRC according Rel-16 A-TRS triggering
framework
·
SCell ID is
configured as a part of the temporary RS configuration. Some SCell IDs derived
from the trigger state triggered by the new MAC-CE may not refer to
to-be-activated SCells that are indicated by the new MAC-CE or the legacy SCell
activation/de-activation MAC-CE
§ FFS: The value zero of the MAC-CE indication means no temporary RS is triggered by the MAC-CE for all to-be-activated SCells
o Note: The down-selection targets at a RAN1 consensus on MAC-CE functionality and the list of RRC parameters for this feature. Any MAC-CE signaling design above are reference concept, its final MAC-CE signaling design is up to RAN2.
R1-2112606 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From Nov 19th GTW session
Agreement
For both Alt 1 and Alt 2 of temporary RS triggering,
· For Alt 1, the gap between temporary RS bursts is explicitly configured.
o A set of possible gap lengths from which the triggering MAC-CE can indicate one from RAN1 perspective. Up to RAN2 to decide details.
· For Alt 2, a gap length is configured by RRC for each temporary RS having two bursts. For different temporary RS, the value of the gap length can be different based on RRC configuration.
· the number of bursts is up to 2. It can be either explicitly configured, or implicitly indicated by the gap configuration (up to RAN2 to decide one)
Agreement
For Alt 2 of temporary RS triggering, to avoid potential impact on the existing CSI-AperiodicTriggerStateList, a separate trigger-state list is used.
· Note: it does not imply that Alt 2 has been selected by RAN2.
Agreement
For the RRC and MAC-CE designs of temporary RS triggering (both Alt1 and Alt2), from functionality perspective, the max number of to-be-activated SCells should be 15, irrespective of triggered number of temporary RS bursts per cell.
· Note: UE capability for the max number of to-be-activated SCells with 2-burst temporary RS is not precluded.
Final summary in R1-2112855.
R1-2111045 Discussion on other aspects for DSS vivo
R1-2111555 Discussion on collision between temporary RS and other signalings Xiaomi
R1-2111919 Remaining issues on the efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2112156 CRS Rate-matching and PDCCH enhancement for DSS Ericsson
Void (not be handled during this e-meeting).
Also include RAN1 impact from RP-201040 (LTE_NR_DC_enh2).
R1-2202791 Session notes for 8.13 (Maintenance on NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC)
[108-e-R17-RRC-DSS] – Ravi (Ericsson)
Email discussion on Rel-17 RRC parameters for DSS
- 1st check point for first LS in [108-e-R17-RRC]: February 24
- Final check point for second LS in [108-e-R17-RRC] if necessary: March 3
From GTW session
Agreement
Update the value range based on the agreement made in this meeting
Agreement
·
(RRC parameter PCell-CCSscaling in RAN1 specs) is configured
from below value set
o {1/7, 3/14, 2/7, 3/7, 1/2, 5/7, 4/7, reserved}
|
WI code |
Sub-feature group |
RAN1 specification |
Section |
RAN2 Parant IE |
RAN2 ASN.1 name |
Parameter name in the spec |
|
Value range |
|
NR_DSS |
CCS from Scell to Pcell) |
38.213 |
10.1.1 |
|
|
PCell-CCSBDscaling |
….. |
8 values |
R1-2202940 Summary of RAN1 agreements for Rel17 NR DSS WI WI rapporteur (Ericsson)
[108-e-R17-RRC-NR-DC] – Frank (Huawei)
Email discussion on Rel-17 RRC parameters for LTE_NR_DC_enh2
- 1st check point for first LS in [108-e-R17-RRC]: February 24
- Final check point for second LS in [108-e-R17-RRC] if necessary: March 3
The thread [108-e-R17-RRC-NR-DC] was not kicked off. See under 8.13.2.
R1-2200914 Discussion on PDCCH scheduling from Scell Huawei, HiSilicon
R1-2201118 Remaining issues on Scell scheduling Pcell vivo
R1-2201174 Maintenance of Cross-Carrier Scheduling from SCell to PCell ZTE
R1-2201298 Discussion on cross-carrier scheduling from SCell to PCell OPPO
R1-2201499 Remaining issues on cross-carrier scheduling enhancements for NR DSS NTT DOCOMO, INC.
R1-2201720 On SCell scheduling PCell transmissions Intel Corporation
R1-2201721 On efficient activation/de-activation for SCells Intel Corporation
R1-2201879 Remaining issues on cross-carrier scheduling from SCell to PCell CMCC
R1-2201935 Remaining issues on cross-carrier scheduling from SCell to PCell Xiaomi
R1-2202037 Remaining details of cross-carrier scheduling from SCell to PCell Samsung
R1-2202052 On Cross-Carrier Scheduling from sSCell to P(S)Cell MediaTek Inc.
R1-2202091 Cross-carrier scheduling (from Scell to Pcell) Lenovo
R1-2202163 Cross-carrier scheduling from an SCell to the PCell/PSCell Qualcomm Incorporated
R1-2202221 Maintenance of enhanced cross-carrier scheduling for DSS Ericsson
R1-2202270 Remining issues on sSCell to Pcell scheduling Nokia, Nokia Shanghai Bell
R1-2202353 Discussion on cross-carrier scheduling from SCell to Pcell LG Electronics
[108-e-NR-DSS-01] – Ravi (Ericsson)
Email discussion for maintenance on cross carrier scheduling (from Scell to Pcell)
- 1st check point: February 25
- Final check point: March 3
R1-2202602 Summary#1 of Email discussion [108-e-NR-DSS-01] Moderator (Ericsson)
From Feb 22nd GTW session
Agreement
·
(RRC parameter PCell-CCSscaling in RAN1 specs) is configured
from below value set
o {1/7, 3/14, 2/7, 3/7, 1/2, 5/7, [reserved1], [reserved2]}
Conclusion
For a UE configured with cross-carrier scheduling from a sSCell to Pcell/PSCell, enableDefaultBeamForCCS can be configured in CrossCarrierSchedulingConfig in the Pcell/PSCell, which configures default beam determination for a PDSCH on the Pcell/PSCell scheduled by a PDCCH on the sSCell.
Agreement
· When UE is configured for CCS from sSCell to P(S)SCell, and if SS set (x_p) of P(S)Cell and SS set (x_s) of sSCell are configured with same searchSpaceId value
o x_s is used for CCS from sSCell to P(S)Cell (Note: already agreed)
o x_s can be used for sSCell self-scheduling
o x_p is not used for P(S)Cell self-scheduling and parameters other than searchSpaceId and nrofCandidates are not configured for that SS set
· Note: RAN2 spec may need some update, but it depends on RAN2 decision.
Decision: As per email decision posted on Mar 1st,
Agreement
· If a DCI format on the P(S)Cell for self-scheduling the P(S)Cell includes X bits and the corresponding DCI format on the sSCell for cross-carrier scheduling the P(S)Cell includes Y bits, |X-Y| bits are padded to the DCI format with the smaller size.
Conclusion
When CCS from sSCell to P(S)Cell is configured, the configuration of Type 3 CSS set for DCI format 2_5 and applicability of the information in the DCI format is same as in Rel-16.
Agreement
The following TP to Section 10.1.1 of TS38.213 (Identical to the TP in Annex A of R1-2202221) is endorsed.
R1-2202840 Summary#4 of Email discussion [108-e-NR-DSS-01] Moderator (Ericsson)
From Mar 2nd GTW session
Agreement
The following TP for 38.214 sub clause 5.1 and 6.1 is endorsed.
|
5.1 UE procedure for receiving the physical downlink shared channel *** Unchanged text is omitted *** For any two HARQ process IDs in a given scheduled cell, if the UE is scheduled to start receiving a first PDSCH starting in symbolj by a PDCCH ending in symbol i on a scheduling cell, the UE is not expected to be scheduled to receive a PDSCH starting earlier than the end of the first PDSCH with a PDCCH that ends later than symbol i of the scheduling cell *** Unchanged text is omitted *** 6.1 UE procedure for transmitting the physical uplink shared channel *** Unchanged text is omitted *** For any two HARQ process IDs in a given scheduled cell, if the UE is scheduled to start a first PUSCH transmission starting in symbol j by a PDCCH ending in symbol i on a scheduling cell, the UE is not expected to be scheduled to transmit a PUSCH starting earlier than the end of the first PUSCH by a PDCCH that ends later than symbol i of the scheduling cell. *** Unchanged text is omitted *** |
Agreement
·
Update (RRC parameter PCell-CCSscaling in RAN1 specs) value set as
below
o {1/7, 3/14, 2/7, 3/7, 1/2, 5/7, 4/7, reserved}
Agreement
·
For a UE configured for CCS
from sSCell to P(S)Cell, scaling factor is not applied for PDCCH overbooking/BD/CCE limit computation when
sSCell is deactivated, or when an activated sSCell is switched to dormant BWP;
otherwise scaling factor is applied
o
Timing for disabling
scaling factor when sSCell is deactivated follows sSCell deactivation timing in
current specifications, i.e., no later than the minimum requirement defined in
TS 38.133 as captured in 38.213 subclause 4.3
o
Timing for disabling
scaling factor follows the non-dormant to dormant BWP switching delay in current
specifications ( TS 38.133).
o
Introduce separate FG to
indicate UE support for disabling scaling factor when sSCell is deactivated
o
Introduce separate FG to
indicate UE support for disabling scaling factor when activated sSCell is switched to dormant BWP
o Note: It is up to UE implementation whether/when to apply the scaling factor α during sSCell activation and during sSCell BWP switch
Final summary in R1-2202906.
R1-2202934 Summary of agreements for Rel-17 feMR-DC WI WI Rapporteur (Huawei)
R1-2200915 Discussion on efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2200997 Support efficient activation/de-activation mechanism for Scells FUTUREWEI
R1-2201119 Remaining issues on efficient activation/de-activation mechanism for Scells vivo
R1-2201175 Maintenance of Efficient Activation De-activation Mechanism for SCells in NR CA ZTE
R1-2201299 Discussion on efficient activation/de-activation for SCell OPPO
R1-2201500 Discussion on efficient activation deactivation mechanism for Scells NTT DOCOMO, INC.
R1-2201936 Remaining issues on efficient activation and de-activation mechanism for SCell in NR CA Xiaomi
R1-2202164 Efficient activation/de-activation mechanism for SCells in NR CA Qualcomm Incorporated
R1-2202222 Maintenance for efficient SCell activation Ericsson
R1-2202271 On RAN2 LSs to RAN1 on TRS-based SCell activation Nokia, Nokia Shanghai Bell
R1-2202354 Discussion on fast and efficient SCell activation in NR CA LG Electronics
R1-2202465 TP on stage 2 description for Rel-17 efficient Scell activation of NR CA Huawei, HiSilicon
[108-e-NR-DSS-02] – Frank (Huawei)
Email discussion for maintenance on efficient activation/de-activation mechanism
- 1st check point: February 25
- Final check point: March 3
R1-2202608 Summary#1 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
R1-2202609 Summary#2 of efficient SCell activation/de-activation mechanism of NR CA Moderator (Huawei)
From Feb 24th GTW session
Agreement
Confirm the RAN2 understanding in Q1 of the LS R1-2200890 for trs-info.
Agreement
Confirm in the reply LS that the following limitations need to be captured in RAN2 spec,
· CSI-RS can only be configured on a BWP with firstActiveDownlinkBWP-Id. (already reflected in draft CR R2-2201714)
· CSI-RS for tracking for fast SCell activation cannot be one with two NZP CSI-RS resources in one slot. (not correctly reflected in R2-2201714 yet)
Agreement
Inform RAN2 that
· Regarding TRS for Scell activation, CSI-RS resources within one CSI-RS resource set should be configured with the same TCI state. To reflect this, the following change is for RAN2 consideration.
|
On top of CR R2-2201714 for TS 38.331 SCellActivationRS-Config information element -- ASN1START -- TAG-SCELLACTIVATIONRS-CONFIG-START
SCellActivationRS-Config-r17 ::= SEQUENCE { scellActivationRS-Id-r17 SCellActivationRS-ConfigId-r17, resourceSet-r17 NZP-CSI-RS-ResourceSetID, gapBetweenBursts-r17 INTEGER (2..31) OPTIONAL, -- Need R
qcl-Info-r17 ... }
-- TAG-SCELLACTIVATIONRS-CONFIG-STOP -- ASN1STOP |
Agreement
The following TP for TS 38.214 is endorsed
|
5.2.1.5.3 Aperiodic CSI-RS for tracking for fast Scell activation When
the UE receives an Enhanced Scell Activation/Deactivation
MAC CE ==================== unchanged parts ==================== |
Agreement
Inform RAN2 that
· Regarding TRS for SCell activation, the reference slot in the following excerpt of TS 38.331 (as highlighted below) is not in line with the RAN1 agreement below, which has been captured in S5.2.1.5.3 of TS 38.214.
· A correction is needed in RAN2 TS 38.331 specification. Whether updating the description or introducing a new RRC parameter name with a link to TS 38.214 is up to RAN2.
|
TS 38.331 text: aperiodicTriggeringOffset, aperiodicTriggeringOffset-r16 Offset X between the slot containing the DCI that triggers a set of aperiodic NZP CSI-RS resources and the slot in which the CSI-RS resource set is transmitted. For aperiodicTriggeringOffset, ……. For aperiodicTriggeringOffset-r16, the value indicates the number of slots. The network configures only one of the fields. When neither field is included, the UE applies the value 0. |
|
Agreement For the reference slot for triggering offset of temporary RS · Option 2: the last DL slot of the to-be-activated Scell overlapping with slot n+k as defined in 38.213 sub-clause 4.3 · FFS: the earliest slot no earlier than the reference slot for a UE to receive a triggered temporary RS Agreement For efficient SCell activation, the earliest slot for a UE to receive a triggered temporary RS is the reference slot (i.e., the last DL slot of the to-be-activated Scell overlapping with slot n+k as defined in 38.213 sub-clause 4.3). |
Note: Once RAN2 confirms the RRC parameter name for the offset, RAN1 may update TS 38.214 to align the RRC parameter name accordingly.
Agreement
Endorse the following TP on stage 2 description for Rel-17 efficient SCell activation of NR CA in TS 38.300. (Note: cyan color formatting only to highlight the difference from before and to be removed from final TP)
· The endorsed TP is sent to RAN2 by a LS
|
----------------------------------------------- TP start------------------------------------------------ 10.6 Activation/Deactivation Mechanism ==== Unchanged parts ==== To enable fast SCell activation when CA is configured, one dormant BWP can be configured for an SCell. If the active BWP of the activated SCell is a dormant BWP, the UE stops monitoring PDCCH and transmitting SRS/PUSCH/PUCCH on the SCell but continues performing CSI measurements, AGC and beam management, if configured. A DCI is used to control entering/leaving the dormant BWP for one or more SCell(s) or one or more SCell group(s). The dormant BWP is one of the UE’s dedicated BWPs configured by network via dedicated RRC signalling. The SpCell and PUCCH Scell cannot be configured with a dormant BWP. To enable fast SCell activation when CA is configured, aperiodic CSI-RS for tracking for fast SCell activation can be configured for an SCell to assist AGC and time/frequency synchronization. A MAC CE is used to trigger activation of one or more SCell(s) and trigger the aperiodic CSI-RS for tracking for fast SCell activation for a (set of) deactivated SCell(s). ==== Unchanged parts ==== ----------------------------------------------- TP end ------------------------------------------------ |
Agreement
· Introduce new FG35-2 additional bandwidth for fast SCell activation.
Working assumption
· The following TP to Section 5.1.6.1.1 of TS38.214 is endorsed
|
----------------------------------------------- TP start------------------------------------------------ ==== Unchanged parts ==== Each CSI-RS resource, defined in Clause 7.4.1.5.3 of [4, TS 38.211], is configured by the higher layer parameter NZP-CSI-RS-Resource with the following restrictions: - the time-domain locations of the two CSI-RS resources in a slot, or of the four CSI-RS resources in two consecutive slots (which are the same across two consecutive slots), as defined by higher layer parameter CSI-RS-resourceMapping, is given by one of - - - a
single port CSI-RS resource with density - if carrier ==== Unchanged parts ==== ----------------------------------------------- TP end ------------------------------------------------ |
Note: set 1 and set 2 are same as the legacy ones.
R1-2202703 [Draft] LS on Stage 2 description for fast SCell activation Moderator (Huawei)
Decision: As per email decision posted on Feb 26th,the draft LS is endorsed. Final LS is approved in R1-2202704.
R1-2202705 [Draft] Reply LS on RAN2 agreements for TRS-based Scell activation Moderator (Huawei)
Decision: As per email decision posted on Feb 26th,the draft LS is endorsed. Final LS is approved in R1-2202706.
Decision: As per email decision posted on Mar 2nd,,
Agreement
The following TP for Section 5.1.6.1.1.1 of TS 38.214 is endorsed.
|
5.1.6.1.1.1 Aperiodic CSI-RS for fast SCell activation A UE can be configured with aperiodic CSI-RS resources for
tracking for an Scell for fast Scell activation using NZP-CSI-RS-ResourceSet(s) with the
higher layer parameter scellActivationRS-ConfigToAddModList ====================unchanged parts ==================== |
Final summary in R1-2202918.
R1-2201937 Remaining issue on dynamic spectrum sharing Xiaomi
R1-2202223 Evaluation of PDCCH enhancement for DSS Ericsson
R1-2202417 Remaining issues on the efficient activation/de-activation mechanism for SCells Huawei, HiSilicon
R1-2205570 Session notes for 8.13 (Maintenance on NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC)
R1-2205179 [109-e-Prep-AI8.13 fMR-DC/CA Enh] Prep phase summary of further MR-DC/CA Enhancement Moderator (Huawei)
R1-2205192 Summary of [109-e-Prep-AI8.13 DSS] Moderator (Ericsson)
R1-2203102 Discussion on NR Dynamic spectrum sharing Huawei, HiSilicon
R1-2203196 Maintenance of DSS and MR-DC ZTE
R1-2203528 Maintenance on Scell scheduling Pcell vivo
R1-2203876 Remaining details of NR dynamic spectrum sharing Samsung
R1-2204005 Remaining issues of cross-carrier scheduling from sSCell to Pcell OPPO
R1-2204624 Remaining issues on Cross-carrier scheduling from Scell to Pcell LG Electronics
R1-2204694 On Cross-Carrier Scheduling from sSCell to P(S)Cell MediaTek Inc.
R1-2204778 On SCell scheduling PCell transmissions Intel Corporation
R1-2204822 NR-DC uplink power sharing when SCG cells are deactivated Nokia, Nokia Shanghai Bell
R1-2204962 Maintenance for Rel-17 DSS Ericsson
R1-2204996 Maintenance on NR Dynamic spectrum sharing Qualcomm Incorporated
[109-e-R17_DSS-01] – Ravi (Ericsson)
Email discussion for moderator’s proposals in the FL summary R1-2205192 for maintenance on DSS
- Discussion and decision by May 18
R1-2205583 Summary of Email discussion [109-e-R17_DSS-01] Moderator (Ericsson)
R1-2205584 Agreed TPs from Email discussion [109-e-R17_DSS-01] Moderator (Ericsson)
Decision: As per email decision posted on May 17th,
Agreement
· Adopt the TP of Proposal-TP1 in R1-2205584 for 38.213 v17.1.0 sub-clause 10.1.
o Note: Whether the change is also made to previous release specification(s) can be discussed in respective maintenance A.I.
Agreement
· Adopt the TP of Proposal-TP2v2 in R1-2205584 for 38.213 v17.1.0 sub-clause 10.1
Decision: As per email decision posted on May 19th,
Agreement
· Agree the TP Proposal-TP3v2 in R1-2205584 for 38.213 v17.1.0 sub-clause 10.1.1
[109-e-R17_DSS-02] – Frank (Huawei)
Email discussion for maintenance on further MR-DC/CA Enhancement, including Issue-1, Issue-2 and Issue-3 of moderator’s proposals in the FL summary R1-2205179
- Discussion and decision by May 18
R1-2205615 Summary of email discussion [109-e-R17_DSS-02] on Further Multi-RAT Dual-Connectivity enhancements Moderator (Huawei)
R1-2205614 Agreed TPs from Email discussion [109-e-R17_DSS-02] Moderator (Huawei)
Decision: As per email decision posted on May 14th,
Agreement
· Adopt to the TP#1 in R1-2205614 for TS 38.213 clause 7.6.2.
· Adopt to the TP#2 in R1-2205614 for TS 38.214 clause5.2.1.5.3.
R1-2208143 Session notes for 8.13 (Maintenance on NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC)
[110-R17-DSS] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Ravi (Ericsson)
R1-2205760 Discussion on minimum scheduling offset restriction Huawei, HiSilicon
R1-2205952 Maintenance of Rel-17 DSS ZTE
R1-2206564 Correction on different SCS between P(S)Cell and sSCell Intel Corporation
R1-2206565 Discussion on different SCS between P(S)Cell and sSCell Intel Corporation
R1-2206806 Discussion on DCI size alignment for Rel-17 DSS Samsung
R1-2206807 Draft CR for DCI size alignment for Rel-17 DSS Samsung
R1-2207667 Correction on dormancy indication on SCell Huawei, HiSilicon
R1-2207668 Correction on dormancy indication on SCell Huawei, HiSilicon
R1-2207835 Summary#1 of Rel17 Maintenance on NR Dynamic spectrum sharing (DSS) Moderator (Ericsson)
R1-2208205 Draft CR on DCI size alignment for Cross-carrier scheduling from SCell to Pcell Moderator (Ericsson), Samsung
Agreement
· The draft CR R1-2208205 is endorsed in principle.
Agreement
Final CR R1-2208246 is endorsed.
R1-2208246 CR on DCI size alignment for Cross-carrier scheduling from SCell to Pcell Moderator (Ericsson), Samsung
Final summary in R1-2208248.
R1-2206430 Disabling EN-DC power split when SCG is deactivated Nokia, Nokia Shanghai Bell
R1-2206431 Section naming correction on the CSI-RS for Tracking for Fast SCell activation Nokia, Nokia Shanghai Bell
R1-2206765 Corrections for efficient SCell activation vivo
R1-2207208 Draft CR on Aperiodic CSI-RS for tracking for fast SCell activation Qualcomm Incorporated
R1-2207436 Corrections for fast SCell activation Ericsson
R1-2207927 Summary#1 of further MR-DC/CA Enhancement Moderator (Huawei)
Agreement
· Draft CR R1-2207208 is endorsed in principle.
Final CR (38.214, Rel-17, CR#0321, Cat F) is agreed in:
R1-2208190 CR on Aperiodic CSI-RS for tracking for fast SCell activation Moderator (Huawei), Qualcomm, Ericsson
For editors:
The following two agreements on spec changes are provided to improve clarity of RAN1 specifications. Please consider them in the next specification revision.
Agreement
· CR R1-2206765 is endorsed in principle for parameter alignment and clarification.
· Note: except the part in 5.2.1.5.3 Aperiodic CSI-RS for tracking for fast SCell activation
Agreement
· CR R1-2206431 is endorsed in principle.
Final summary in R1-2208286.
R1-2210781 Session notes for 8.13 (Maintenance on NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC) (rev of R1-2210688)
R1-2208621 Corrections on Scell scheduling Pcell vivo
R1-2209036 Correction on different SCSs between P(S)Cell and sSCell Intel Corporation
R1-2209037 Discussion on different SCSs between P(S)Cell and sSCell Intel Corporation
R1-2209450 Discussion on simultaneous PDCCH monitoring between USS set on sSCell and CSS set on PCell LG Electronics
R1-2209469 Draft CR for Rel-17 DSS ZTE
R1-2209851 Correction for DCI size alignment for Rel-17 DSS Huawei, HiSilicon
R1-2209962 Discussion on clarification for cross-carrier scheduling from SCell to P(S)Cell Qualcomm Incorporated
R1-2210191 Disabling EN-DC power split when SCG is deactivated Nokia, Nokia Shanghai Bell
[110bis-e-R17-DSS-01] Email discussion to determine maintenance issues to be handled in RAN1#110bis-e by October 12 – Ravi (Ericsson)
- Additional email discussions will be set up once the maintenance issues for RAN1#110bis-e are determined
R1-2210441 Summary#2 of Email discussion [110bis-e-R17-DSS-01] Moderator (Ericsson)
Decision: As per email decision posted in Oct 11th, the topics 2,3,4,5,6 (section 2 of R1-2210441) are selected for further discussion.
From Oct 12th GTW session
Agreement
· Adopt below change to 38.213 sub-clause 10.1.1 as part of alignment CR.
![Text Box: 10.1.1 Self-carrier and cross-carrier scheduling on the primary cell
A UE can be configured for scheduling on the primary cell from the primary cell and from a secondary cell [12, TS 38.331]. The UE is either not provided monitoringCapabilityConfig for the primary cell or for the secondary cell, or the UE is provided only monitoringCapabilityConfig = r15monitoringcapability for the primary cell and for the secondary cell. The UE is not provided coresetPoolIndex on the primary cell or on the secondary cell.
The SCS configuration μ_P for the active DL BWP on the primary cell is smaller than or equal to the SCS configuration μ_S for the active DL BWP on the secondary cell.
<Unchanged parts are omitted>](Final_Minutes_report_RAN1%23110b-e_v100_files/image084.png){kind=small}
Decision: As per email decision posted in Oct 19th,
Agreement
· Adopt the TP to TS 38.212 subclause 7.3.1.1.2.
|
For a UE configured with scheduling on the primary cell from an SCell, if prior to padding the number of information bits in DCI format 0_1 carried by PDCCH on the primary cell is not equal to the number of information bits in DCI format 0_1 carried by PDCCH on the SCell for scheduling on the primary cell, zeros shall be appended to the DCI format 0_1 with smaller size until the payload size is the same. § If application of step 4C in clause 7.3.1.0 results in additional zero padding for DCI format 0_1 for scheduling on the primary cell, corresponding zeros shall be appended to both DCI format 0_1 monitored on the primary cell and DCI format 0_1 monitored on the SCell for scheduling on the primary cell.
§ If the SCell is deactivated and firstActiveDownlinkBWP-Id is not set to dormant BWP, the UE determines the number of information bits in DCI format 0_1 carried by PDCCH on the primary cell based on a DL BWP provided by firstActiveDownlinkBWP-Id for the SCell. If the active DL BWP of the SCell is a dormant DL BWP, or if the SCell is deactivated and firstActiveDownlinkBWP-Id is set to dormant BWP, the UE determines the number of information bits in DCI format 0_1 carried by PDCCH on the primary cell based on a DL BWP provided by firstWithinActiveTimeBWP-Id for the SCell if provided; otherwise, based on a DL BWP provided by firstOutsideActiveTimeBWP-Id for the SCell. |
Agreement
· Adopt the TP to TS 38.212 subclause 7.3.1.1.3.
|
For a UE configured with scheduling on the primary cell from an SCell, if prior to padding the number of information bits in DCI format 0_2 carried by PDCCH on the primary cell is not equal to the number of information bits in DCI format 0_2 carried by PDCCH on the SCell for scheduling on the primary cell, zeros shall be appended to the DCI format 0_2 with smaller size until the payload size is the same. § If application of step 4B in clause 7.3.1.0 results in additional zero padding for DCI format 0_2 for scheduling on the primary cell, corresponding zeros shall be appended to both DCI format 0_2 monitored on the primary cell and DCI format 0_2 monitored on the SCell for scheduling on the primary cell.
§ If the SCell is deactivated and firstActiveDownlinkBWP-Id is not set to dormant BWP, the UE determines the number of information bits in DCI format 0_2 carried by PDCCH on the primary cell based on a DL BWP provided by firstActiveDownlinkBWP-Id for the SCell. If the active DL BWP of the SCell is a dormant DL BWP, or if the SCell is deactivated and firstActiveDownlinkBWP-Id is set to dormant BWP, the UE determines the number of information bits in DCI format 0_2 carried by PDCCH on the primary cell based on a DL BWP provided by firstWithinActiveTimeBWP-Id for the SCell if provided; otherwise, based on a DL BWP provided by firstOutsideActiveTimeBWP-Id for the SCell. |
Agreement
· Adopt the TP to TS 38.212 subclause 7.3.1.2.2.
|
For a UE configured with scheduling on the primary cell from an SCell, if prior to padding the number of information bits in DCI format 1_1 carried by PDCCH on the primary cell is not equal to the number of information bits in DCI format 1_1 carried by PDCCH on the SCell for scheduling on the primary cell, zeros shall be appended to the DCI format 1_1 with smaller size until the payload size is the same. § If application of step 4C in clause 7.3.1.0 results in additional zero padding for DCI format 1_1 for scheduling on the primary cell, corresponding zeros shall be appended to both DCI format 1_1 monitored on the primary cell and DCI format 1_1 monitored on the SCell for scheduling on the primary cell.\ § If the SCell is deactivated and firstActiveDownlinkBWP-Id is not set to dormant BWP, the UE determines the number of information bits in DCI format 1_1 carried by PDCCH on the primary cell based on a DL BWP provided by firstActiveDownlinkBWP-Id for the SCell. If the active DL BWP of the SCell is a dormant DL BWP, or if the SCell is deactivated and firstActiveDownlinkBWP-Id is set to dormant BWP, the UE determines the number of information bits in DCI format 1_1 carried by PDCCH on the primary cell based on a DL BWP provided by firstWithinActiveTimeBWP-Id for the SCell if provided; otherwise, based on a DL BWP provided by firstOutsideActiveTimeBWP-Id for the SCell. |
Agreement
· Adopt the TP to TS 38.212 subclause 7.3.1.2.3.
|
For a UE configured with scheduling on the primary cell from an SCell, if prior to padding the number of information bits in DCI format 1_2 carried by PDCCH on the primary cell is not equal to the number of information bits in DCI format 1_2 carried by PDCCH on the SCell for scheduling on the primary cell, zeros shall be appended to the DCI format 1_2 with smaller size until the payload size is the same. § If application of step 4B in clause 7.3.1.0 results in additional zero padding for DCI format 1_2 for scheduling on the primary cell, corresponding zeros shall be appended to both DCI format 1_2 monitored on the primary cell and DCI format 1_2 monitored on the SCell for scheduling on the primary cell.
§ If the SCell is deactivated and firstActiveDownlinkBWP-Id is not set to dormant BWP, the UE determines the number of information bits in DCI format 1_2 carried by PDCCH on the primary cell based on a DL BWP provided by firstActiveDownlinkBWP-Id for the SCell. If the active DL BWP of the SCell is a dormant DL BWP, or if the SCell is deactivated and firstActiveDownlinkBWP-Id is set to dormant BWP, the UE determines the number of information bits in DCI format 1_2 carried by PDCCH on the primary cell based on a DL BWP provided by firstWithinActiveTimeBWP-Id for the SCell if provided; otherwise, based on a DL BWP provided by firstOutsideActiveTimeBWP-Id for the SCell |
Corresponding draft CRs for above 4 TPs in:
R1-2210718 CR on DCI size alignment for Cross-carrier scheduling from SCell to Pcell Moderator (Ericsson), Huawei, HiSilicon, Samsung
Decision: As per email decision posted in Oct 22nd, the draft CR is endorsed in principle. Final CR (TS 38.212, Rel-17, CR#0130, Cat F) is agreed in R1-2210770.
Final summary in R1-2210780 Summary#3 of Email discussion [110bis-e-R17-DSS-01] Moderator (Ericsson)
R1-2212842 Session notes for 8.13 (Maintenance on NR Dynamic spectrum sharing (DSS)) Ad-hoc Chair (CMCC)
Endorsed and contents incorporated below.
[111-R17-DSS] – Ravi (Ericsson)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2211492 Remaining issue in Rel-17 SCell-to-PCell scheduling OPPO
R1-2212096 Clarification for cross-carrier scheduling from SCell to P(S)Cell Qualcomm Incorporated
R1-2212162 Clarifications for Cross-carrier scheduling from SCell to P(S)Cell Ericsson
R1-2212784 Summary#1 of Rel17 Maintenance on NR Dynamic spectrum sharing (DSS) Moderator (Ericsson)
Agreement
Clarify capability description for FG 34-1 and 34-2 by including following note:
· Note: Parameters in CSI-MeasConfig of P(S)Cell and sSCell are configured such that combination of P(S)Cell and sSCell configurations does not result in exceeding any of the UE’s capabilities for A-/SP-CSI reporting on PUSCH on P(S)Cell
No contributions submitted to RAN1#112.
